[swift, interop] Swift API level changes to reflect in Interop
Arkady.Kanevsky at dell.com
Arkady.Kanevsky at dell.com
Sat Jun 6 01:58:19 UTC 2020
From: Tim Burke <tburke at nvidia.com>
Sent: Friday, June 5, 2020 6:54 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: [swift, interop] Swift API level changes to reflect in Interop
On 6/5/20 12:27 PM, Arkady.Kanevsky at dell.com wrote:
> Swift team,
> Need you response, please, on API changes for swift APIs in Ussuri cycle.
> -----Original Message-----
> From: Ghanshyam Mann <gmann at ghanshyammann.com>
> Sent: Monday, June 1, 2020 12:34 PM
> To: Kanevsky, Arkady
> Cc: openstack-discuss
> Subject: Re: [swift, interop] Swift API level changes to reflect in
> [EXTERNAL EMAIL]
> ---- On Mon, 01 Jun 2020 11:27:16 -0500 <Arkady.Kanevsky at dell.com> wrote ---- > As we create new guidelines for Interop, > We need to see what changes needed for object storage guidelines.
> > So a few specific questions for Swift team:
> > 1. What new Tempest tests added for Ussuri release?
> > a. APIs for query and accessing older versions? Is it for S3 APIs or for swift API also?
> > b. Any new or modified Tempest test for Etags?
> > c. Any SIGUSR1 test coverage?
> > d. New tempest tests for swift-ring-builder?
> > 2. What are tempest tests deprecated for Ussuri release?
> > a. Any tempest tests removed for auto_create_account_prefix?
> We do not deprecate the Tempest test anytime. Tests can be removed if
> it satisfies the Tempest test-removal policy -
> Also adding test in Tempest is also not necessary to happen when API is introduced, it can be later so it is hard to tell when that API was introduced from the Tempest test addition.
> So from the Tempest side, it will not be a clear pic on what all API/capabilities are added/deprecated in which cycle. From the Tempest point of view, there is no difference between deprecated vs non-deprecated APIs, we keep testing it until those are not removed. For example, you can still run Tempest for Cinder v2 APIs.
> I think swift team can tell from their API changes not from what changed in Tempest.
> > Any other API test coverage tests missed above?
> > Thanks,
> > Arkady
Sorry for the delay. To my knowledge, no one on the Swift team has added or deprecated any Tempest tests. Some more specific details about recent
The new object versioning APIs affect both Swift and S3 access. For more information about the new Swift versioning API, see https://docs.openstack.org/swift/latest/middleware.html#object-versioning.
For more information about the S3 versioning API, see https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html; we've reproduced the S3 behaviors as faithfully as we could and any differences should be reported as bugs.
I don't know what expectations Tempest has around ETags; it may be that no changes are warranted even if the service defaults to RFC-compliant ETags. At any rate, the default ETag quoting behavior is unlikely to change in the near future (measured in years).
I'm not sure that USR1 signal handling would really be in-scope for Tempest. I was under the impression that Tempest was performing blackbox testing (and so would not deal with service management issues), though I'd welcome any corrections in my understanding.
Along the same lines, swift-ring-builder seems out of scope as well.
The auto_create_account_prefix change should not change any client-facing behaviors; rather, it simply moved a config option to a more suitable location.
More information about the openstack-discuss