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

Bump API microversion to 3.50

2018-01-23T16:36:00+00:00

This change is to bump MAX_VERSION to
3.50 in api_version.  This bump is necessary to
keep cinderclient in sync with cinder which moved
to 3.50 with change: f1bfd9790d2a7cac9a3e66417b11dc8e3edd8109

With MV 3.50 we are able to request multiple attachments for
a single volume.

Change-Id: Ic51b890b816112cecaedd68df8d13ec175623c66

Support for reporting backend state in service list

2018-01-09T01:04:00+00:00

This patch will support the feature: report backend state in service list
in client side.

Depends-On: I561dca3ef7c1901401621bc112389dbd178a907e

Change-Id: If15e1fa50b5feecd74c7394c918f4fc9d87bcf3e
Implements: blueprint report-backend-state-in-service-list

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