delta/openstack/python-cinderclient.git/cinderclient/api_versions.py, branch 3.3.0

Bump Max API version to 3.48

2017-12-07T20:46:56+00:00

In order for Nova to be able to make use of the code
for shared_targets that has gone into Cinder we need to
bump to API Version to 3.48.

This bumps to 3.48 to match the latest add to the Cinder side:
    https://review.openstack.org/#/c/524697/1

Change-Id: Icaa17654bd2810098d02f8074fedb35c5221cd55

Support create volume from backup in client

2017-12-07T03:31:39+00:00

This patch adds create volume from backup support
in cinderclient.

Change-Id: I01dbcf6b113d88732c174b848be2127ee7242b3c
Implements: blueprint support-create-volume-from-backup
Depends-On: 58d0fb327f9fc980e0c8b84dcd9f64c093285d13

Bump Max version to 3.46

2017-12-07T00:41:00+00:00

Bump max version in client directly as
the client changes are not needed.

1. 3.46: support create bootable volume from nova
         0 size image.

Change-Id: Ib0cf2d88e55006c10b873327ccc85dca2dd09769

Support list with 'with_count' in client

2017-12-05T01:15:19+00:00

Add 'with_count' parameter in list
volume, snapshot and backup APIs.

Change-Id: I2b7b41b3579c24703a7a67ab5dc6f960a3ccbdc2
Partial-Implements: bp add-amount-info-in-list-api

Revert "Bump MAX version of client to 3.45"

2017-10-30T17:47:53+00:00

3.45 has landed, but it's not the expected change.

This reverts commit 664299b235be69ae35670d96fb70e62836b9b5b0.

Change-Id: I39e93c6078871f8652889cf8a46c1af6962288e4

Bump MAX version of client to 3.45

2017-09-26T19:17:04+00:00

Adding a shared_targets field to Volumes in Cinder.  This doesn't
require any changes in the client, however we do need to bump the
MAX MV support value.

Show volumes now returns two new fields that will be displayed in
the show command:
    shared_targets: 
    backend_name:  

Change-Id: Ie1291f90756c3752de562f022126af2f6b3e0637

Merge "Enable H306"

2017-08-22T14:34:25+00:00

Add an attachment_complete API call

2017-08-14T16:27:44+00:00

The new attachment_update method in Cinder's API creates an attachment
object and populates it with the provided connector info. In addition,
we set the volumes status to in-use and update the attachment object
status to "attached".

This isn't really accurate though, because we don't know if the volume
is actually attached (connected) by the consumer or not.  Also a big
side effect here is that currently all of our tests and automation
use volume-status to determine if a volume is fully connected/ready
for use and that everything went well.  It's used as an ack in most
cases.

This change goes back to using multiple states to signify where a
an attachment is in it's life-cycle:
1. attachment_create
    We've created an empty attachment record but haven't done anything
    with it yet.
2. attachment_update
    We provided a connector and set up the TGT so that everything is
    ready for a consumer to connect/use it.
3. attachment_complete
    An ACK back from the consumer letting us know that they connected
    it successfully and are doing their thing.

It would be cool to just key all these checks of the attachment object itself,
and just use attachment_update to do so, maybe in the future?

Change-Id: I3b28d2cb89a8d81c7cdec425f355c78bfdfe3450
Related-Bug: #1710295

Enable H306

2017-08-01T20:23:49+00:00

Enforce ordering of imports with H306.

For tests, this is mostly done by grouping test
imports after other cinderclient imports.

Change-Id: Ie40fda014d1aedb057e5b4ea1f27f999c84e6373

Merge "Handle AttributeError in _get_server_version_range"

2017-07-26T00:37:52+00:00