[swift, interop] Swift API level changes to reflect in Interop
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? Any other API test coverage tests missed above? Thanks, Arkady
---- On Mon, 01 Jun 2020 11:27:16 -0500 <Arkady.Kanevsky@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 - https://docs.openstack.org/tempest/latest/test_removal.html 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. -gmann
Any other API test coverage tests missed above? Thanks, Arkady
Thanks for clarification Ghanshyam -----Original Message----- From: Ghanshyam Mann <gmann@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 Interop [EXTERNAL EMAIL] ---- On Mon, 01 Jun 2020 11:27:16 -0500 <Arkady.Kanevsky@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 - https://docs.openstack.org/tempest/latest/test_removal.html 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. -gmann
Any other API test coverage tests missed above? Thanks, Arkady
Swift team, Need you response, please, on API changes for swift APIs in Ussuri cycle. Thanks, Arkady -----Original Message----- From: Ghanshyam Mann <gmann@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 Interop [EXTERNAL EMAIL] ---- On Mon, 01 Jun 2020 11:27:16 -0500 <Arkady.Kanevsky@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 - https://docs.openstack.org/tempest/latest/test_removal.html 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. -gmann
Any other API test coverage tests missed above? Thanks, Arkady
On 6/5/20 12:27 PM, Arkady.Kanevsky@dell.com wrote:
Swift team, Need you response, please, on API changes for swift APIs in Ussuri cycle. Thanks, Arkady
-----Original Message----- From: Ghanshyam Mann <gmann@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 Interop
[EXTERNAL EMAIL]
---- On Mon, 01 Jun 2020 11:27:16 -0500 <Arkady.Kanevsky@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 - https://docs.openstack.org/tempest/latest/test_removal.html
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.
-gmann
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 changes: 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. Tim
Thanks Tim. -----Original Message----- From: Tim Burke <tburke@nvidia.com> Sent: Friday, June 5, 2020 6:54 PM To: openstack-discuss@lists.openstack.org Subject: Re: [swift, interop] Swift API level changes to reflect in Interop [EXTERNAL EMAIL] On 6/5/20 12:27 PM, Arkady.Kanevsky@dell.com wrote:
Swift team, Need you response, please, on API changes for swift APIs in Ussuri cycle. Thanks, Arkady
-----Original Message----- From: Ghanshyam Mann <gmann@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 Interop
[EXTERNAL EMAIL]
---- On Mon, 01 Jun 2020 11:27:16 -0500 <Arkady.Kanevsky@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 - https://docs.openstack.org/tempest/latest/test_removal.html
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.
-gmann
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 changes: 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. Tim
---- On Fri, 05 Jun 2020 18:54:10 -0500 Tim Burke <tburke@nvidia.com> wrote ----
On 6/5/20 12:27 PM, Arkady.Kanevsky@dell.com wrote:
Swift team, Need you response, please, on API changes for swift APIs in Ussuri cycle. Thanks, Arkady
-----Original Message----- From: Ghanshyam Mann <gmann@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 Interop
[EXTERNAL EMAIL]
---- On Mon, 01 Jun 2020 11:27:16 -0500 <Arkady.Kanevsky@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 - https://docs.openstack.org/tempest/latest/test_removal.html
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.
-gmann
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 changes:
Yeah, swift tests are very much changes since they were added. We kept them working for interop requirements.
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.
That is correct. Tempest tests which verifying the behaviour on API (from interop PoV), should not have any impact. If they are passing (which is yes as per gate results) then changes in swift are ok until those are not config driven. -gmann
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.
Tim
participants (3)
-
Arkady.Kanevsky@dell.com
-
Ghanshyam Mann
-
Tim Burke