Bug 1031007

Summary: [RFE] [Nova] Cancelling a swap volume
Product: Red Hat OpenStack Reporter: Stephen Gordon <sgordon>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: hateya, markmc, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_drafting
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-15 13:22:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.