Open Stack

John,

This is very new. There has been intention to make this a standard in Tempest tests for a year now, and we finally found the resources to push an implementation through. I think that following the Tempest lead and decorating tests with a uuid of the same or similar format (@test.idempotent_id(‘12345678-1234-1234-1234-1234-123456789abc’)) would future proof the tests against any potential refactoring and make the identification in capabilities consistent across all of the projects.

-Chris


> On Feb 27, 2015, at 2:35 PM, John Dickinson <me at not.mn> wrote:
> 
> That is interesting. I'll certainly bring it up with the rest of the Swift contributors, and, on the surface, it seems possible.
> 
> As I mentioned, the tests-have-UUIDs is new to me (and it seems to have only very recently landed in tempest). The test names in Swift's functional tests are very stable. While I'm not opposed to figuring out how a UUID scheme for tests might work, can we move forward with mapping them to capabilities while other discussions happen with UUIDs?
> 
> 
> --John
> 
> 
> 
> 
> 
> 
>> On Feb 27, 2015, at 10:11 AM, Mark Voelker <mvoelker at vmware.com> wrote:
>> 
>> Signed PGP part
>> Just so.  Background info:
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2015-February/057923.html
>> 
>> At Your Service,
>> 
>> Mark T. Voelker
>> 
>> On Feb 27, 2015, at 9:27 AM, Monty Taylor <mordred at inaugust.com> wrote:
>> 
>> Signed PGP part
>> On 02/27/2015 12:18 PM, John Dickinson wrote:
>>> Rob, is that question directed to me? I'm not sure what a test UUID
>>> is.
>> 
>> They added UUIDs to tempest tests so that as test names or re-org'd,
>> the defcore mapping didn't have to implode. So I think the question is
>> about the feasibility of doing such a thing in the swift functional tests.
>> 
>>> --John
>>> 
>>> 
>>> 
>>> 
>>>> On Feb 25, 2015, at 3:58 PM, Rob Hirschfeld <rob at zehicle.com>
>>>> wrote:
>>>> 
>>>> Good question. Can those tests also get UUIDs?
>>>> 
>>>> On Feb 25, 2015 5: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
>>> 
>>>>> 
>>> 
>>> 
>>> _______________________________________________ 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
>> 
>> 
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee