[OpenStack-DefCore] Some Governance Patches To Be Aware Of

John Dickinson me at not.mn
Fri May 6 20:53:56 UTC 2016



On 6 May 2016, at 13:39, Monty Taylor wrote:

> On 05/06/2016 03:28 PM, John Dickinson wrote:
>>
>>
>> On 6 May 2016, at 10:03, Mark Voelker wrote:
>>
>>> Hi Folks,
>>>
>>> For those of you who didn’t catch it elsewhere, here are a couple of DefCore-related things that the TC is currently considering that you may want to be aware of:
>>>
>>> "add resolution explaining which tests we think defcore should use"
>>> https://review.openstack.org/#/c/312718/
>>
>> Should this resolution pass, what incentive remains to write a Tempest plugin?
>>
>> Currently the object storage project is working on a Tempest plugin so that our in-tree functional tests may be used as part of the DefCore validation suite. That work seems like needless code churn now. If in-tree tests are specifically discouraged for being used in DefCore compliance checks, this removes the incentive to use Tempest's plugin capabilities. Does this resolution thus imply that the Tempest plugin capability will be going away at some point?
>
> I do not think so. tempest still handles a ton of the common openstack needs and abstractions. While porting swift's functional tests to tempest might be a chore for swift currently, I don't think the same is true broadly - where the existence of a framework and the existence of hooks to integrate that with devstack are super helpful.

I'm not concerned by porting tests being a "chore" or not. First, I don't expect tests to leave the swift source tree, regardless of what tests are elsewhere. Second, I don't have much hope that contributors managing the swift repo will also start managing the tempest repo. This is the main issue. Unless swift devs are actively involved in curating, writing, and maintaining tests in a non-swift repo, I don't expect that external repo to be as actively managed or provide as much coverage as the in-tree tests. Additionally, separating the tests from the implementation forces these things to land separately, meaning that by definition we will have untested (by tempest) code in swift.


--John



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20160506/a5595cb0/attachment.pgp>


More information about the Defcore-committee mailing list