Open Stack

 ---- On Fri, 05 Jun 2020 18:54:10 -0500 Tim Burke <tburke at nvidia.com> wrote ----
 > 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.
 > > Thanks,
 > > Arkady
 > >
 > > -----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 Interop
 > >
 > >
 > > [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 - 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
 > 
 > 
 >