Different behavior when user gets list of resources of non-existent stack by stack id and name

Bug #1460744 reported by Anastasia Kuznetsova
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Invalid
Undecided
Pradeep Kumar Singh
openstack-api-site
Fix Released
Low
Pradeep Kumar Singh

Bug Description

Steps to reproduce:
1. heat stack-create --template-file test_stack.yaml -P network=net_id -P InstanceType=m1.small -P ImageId=TestVM test
2. heat stack-list (execute to be sure that stack was created)
3. heat resource-list test (execute to check that all stack resources were created and we can get list of resources using stack _name_)
4. heat resource-list <stack_id> (execute to check that all stack resources were created and we can get list of resources using stack _id_)
5. heat stack-delete test
6. heat stack-list (execute it to be sure that stack was deleted)
7. heat resource-list test (user got: Stack not found: test)
8. heat resource-list <stack_id> (user got list of stack resources with DELETE_COMPLETE statuses)

Observed result:
User has to see "Stack not found" exception after execution step 8

summary: - Different behavior when user get list of resources of non-existent stack
- by stack id and name
+ Different behavior when user gets list of resources of non-existent
+ stack by stack id and name
Revision history for this message
Steve Baker (steve-stevebaker) wrote :

I can't see how this behaviour can be any different. Stacks are soft-deleted so are still accessible via UUID. Also we enforce unique stack names on non-deleted stacks.

I'm inclined to just document that deleted stacks can only be fetched via UUID.

Changed in heat:
assignee: nobody → pradeep kumar singh (pradeep-singh-u)
Revision history for this message
Pradeep Kumar Singh (pradeep-singh-u) wrote :

Hi Steve,

Which place can be better for documenting this?
Thanks :)

Revision history for this message
Steve Baker (steve-stevebaker) wrote : Re: [Bug 1460744] Re: Different behavior when user gets list of resources of non-existent stack by stack id and name

On 03/06/15 02:23, pradeep kumar singh wrote:
> Which place can be better for documenting this?
The api-ref[1] for the following REST call should clarify that for /v1/​
{tenant_id}​/stacks/​{stack_name}​/resources the canonical URL will only
be returned for non-deleted stacks, and the /v1/​{tenant_id}​/stacks/
{stack_name}​/​{stack_id}​/resources form should be used to fetch the
resource list of deleted stacks.

http://developer.openstack.org/api-ref-orchestration-v1.html

Revision history for this message
Pradeep Kumar Singh (pradeep-singh-u) wrote :
Changed in heat:
status: New → In Progress
Changed in heat:
status: In Progress → Invalid
Changed in openstack-api-site:
assignee: nobody → pradeep kumar singh (pradeep-singh-u)
status: New → In Progress
importance: Undecided → Low
milestone: none → liberty
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to api-site (master)

Reviewed: https://review.openstack.org/187860
Committed: https://git.openstack.org/cgit/openstack/api-site/commit/?id=b373ae601fa7829a682d4ee67de5355dbac5318e
Submitter: Jenkins
Branch: master

commit b373ae601fa7829a682d4ee67de5355dbac5318e
Author: Pradeep Kumar Singh <email address hidden>
Date: Wed Jun 3 10:39:46 2015 +0530

    Modify "/v1/{tenant_id}/stacks/{stack_name}/resources" API detail

    This patch modifies api-ref[1] for the following REST call detail,
    /v1/{tenant_id}/stacks/{stack_name}/resources
    It explains for /v1/{tenant_id}/stacks/{stack_name}/resources,
    the canonical URL will only be returned for non-deleted stacks,
    and the /v1/{tenant_id}/stacks/{stack_name}/{stack_id}/resources
    form should be used to fetch the resource list of deleted stacks.

    [1] http://developer.openstack.org/api-ref-orchestration-v1.html

    Closes-Bug: #1460744

    Change-Id: I7024193aafe7e7c90a7ac165b23431f469ce6d69

Changed in openstack-api-site:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.