Open Stack

Mark, it's great to hear you're still looking at external tests, and thanks for the reminder about this testing the Icehouse release.

Swift has had in-tree functional tests since the beginning (Austin release), and below I've linked the output of the Icehouse tests (including the test names). In Icehouse, Swift had 279 functional tests. Also, the in-tree functional tests can be run against any arbitrary Swift endpoint, so it is repeatable and testable and available for anyone to use and verify their Swift deployment[1].

https://gist.github.com/notmyname/5545cde4d726cfa2ce32

All of these tests are against the public API and there is no requirement of any internal knowledge of the target (tested) system.

I'd love to see these tests be included in the DefCore definition along side the Swift capabilities.

--John


[1] ...simply by setting the appropriate endpoint and auth credentials in a config file. Here's the well-commented sample file: https://github.com/openstack/swift/blob/master/test/sample.conf


> On Feb 26, 2015, at 8:08 AM, Mark Voelker <mvoelker at vmware.com> wrote:
> 
> Signed PGP part
> John,
> 
> This was actually discussed during a couple of DefCore meetings, so I think it’s something that is being considered (but thanks for raising it again!).  The basic premise here is that we’re not necessarily tied to a particular testing tool going forward—it’s just that Tempest is where tests for these capabilities are at today.  Bear in mind that 2015.03 is basically looking at Icehouse, which is before the functional test migrations really started gaining steam.
> 
> At Your Service,
> 
> Mark T. Voelker
> OpenStack Architect
> 
> On Feb 25, 2015, at 3:30 PM, John Dickinson <me at not.mn> wrote:
> 
> Looks like all of the tests mentioned are still focused on tempest. Since many projects are moving towards in-tree functional tests, how can those be reflected in the listed tests. For example, i'd love to also use the swift in-tree functional tests for referenced swift capabilities.
> 
> --John
> 
> 
> 
> 
> 
> 
> On Feb 25, 2015, at 3:11 PM, Van Lindberg <van.lindberg at rackspace.com> wrote:
> 
> Should we forward this on to the board?
> 
> From: Van Lindberg <van.lindberg at rackspace.com>
> Date: Wednesday, February 25, 2015 at 1:51 PM
> To: "defcore-committee at lists.openstack.org" <defcore-committee at lists.openstack.org>
> Cc: Egle Sigler <egle.sigler at rackspace.com>, Adrian Otto <adrian.otto at rackspace.com>
> Subject: [OpenStack-DefCore] Draft 2015.03 Spec
> 
> Hello all
> 
> Per the discussion today and at the face to face meeting last week, we have the following draft 2015.03 spec for comments and approval:
> 
> https://etherpad.openstack.org/p/defcore-draft-spec-2015.03
> 
> Notes:
> - There are two advisory sections: auth-token (which we created a placeholder for) and compute-servers-metadata (which didn’t exist in havanacore, but was in icehousecore). Because the point of this doc is “havanacore - anything possibly troublesome,” we suggested moving compute-servers-metadata to advisory for action in 2015.04.
> - This is .rst formatted and designed for human consumption. There is a linked (and also authoritative) .json file for machine consumption.
> - The .json file (draft in gdoc for easy multi-editing right now) has everything that is not mandatory or advisory removed.
> - We updated the versioning of the .json file (to 1.1), removed “status” from the top-level, and added “advisory” flags for those two items that were advisory. We also updated “core” to false for the two advisory items.
> - We need designated sections for keystone.
> 
> Thanks,
> Van
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20150226/5b18106b/attachment.pgp>