Bug 1031007 - [RFE] [Nova] Cancelling a swap volume
Summary: [RFE] [Nova] Cancelling a swap volume
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/nova...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-15 13:21 UTC by Stephen Gordon
Modified: 2014-03-21 04:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-15 13:22:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Stephen Gordon 2013-11-15 13:21:09 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume

Description:

-- Description --
* In this blueprint, I suggest ClientToken that user can specify, and post
  requests which idempotency is guaranteed by the previous ClientToken.
* First, ClientToken is implemented in the run_instance of AmazonEC2.
  It is also implemented in Openstack EC2 run_instance.
  - https://bugs.launchpad.net/nova/+bug/1188327
  - https://review.openstack.org/#/c/32060/
* I think that there is no reason to ClientToken is limited to only the run_instance.
  I suggest implementation of ClientToken to other Openstack API.
* This suggestion is based on following exchange...
  - https://lists.launchpad.net/openstack/msg13082.html

-- Use cases --
1. User AAA boot own server.
2. Unfortunately, the client has gone down.
3. AAA is no way to know how was his server.(In fact, his server runs normally.)
4. AAA thought booting is failure, so AAA booted a new server with same param request as 3.

* This appears to be no problems at first glance, but money problems may occur in service.
(There is a possibility that the overage charges for two servers.)

So AAA need to way how is his server, how is his server status.
In this case, idempotency client token is so useful.
To specify the token itself by AAA, AAA can know status of server.
How many times AAA put POST method, it is guaranteed the state of the POST which was same with return of AAA's first POST request.

-- How to use? --
In curl command, you add header of request 'X-Client-Token: foo'.
In this name, I already implemented python-novaclient implementation.
So, you can put request like 'nova --x-client-token boot --flavor 1 --image hoge ...'
If 'X-Client-Token' become another good name, I am going to refoctor.
In this page, I paste curl command sample.
   https://github.com/ntt-sic/nova/commit/c9bc157b122907d7bd7e98b364137b7ecd47bd0f

-- Configuration --
You don't need any specific permission and policies.
Only just you put or not. It does not affect in the configuration.
If you don't put it, that API works same as before.

-- Implements --
* Plan to implement ClientToken across POST method of whole Openstack for idempotency.
In OpenstackAPI, ClientToken shall be specified in the header.

-- Remaining challenges --
I implemented idempotent.py temporarily.
Appropriate file path is need to be considered.
This feature is decorator. And I applied this decorator to 'Create Server'.
In nova, I also applied it to create keypair.
I am going to apply other nova POST method.
About other component, basic POST, I am able to confirm that the API movement.

-- I assume the code like this. --
https://github.com/ntt-sic/nova/tree/idempo (Nova)
nova/nova/openstack/common/idempotent.py
nova/nova/api/openstack/compute/servers.py

Comment 2 Stephen Gordon 2013-11-15 13:22:59 UTC
Incorrectly mixed two separate blueprints, closing.


Note You need to log in before you can comment on or make changes to this bug.