[Deepsea-users] Teuthology is not for unit testing

Jan Fajerski jfajerski at suse.com
Mon Dec 5 02:08:11 MST 2016

On Mon, Dec 05, 2016 at 06:55:17PM +1100, Tim Serong wrote:
>On 12/03/2016 09:54 AM, Nathan Cutler wrote:
>> Sorry I was not subscribed until just now.
>> Let me say I heartily agree with the general direction of Ricardo's
>> proposal, i.e. that automated PR validation testing is desirable/needed.
>> Jan makes a good point that any meaningful testing of DeepSea requires
>> that a Ceph cluster be deployed.
>> Right now, DeepSea expects that cluster to be on a certain minimum
>> number of nodes?
>DeepSea's validate runner (invoked at the start of stage 3/deploy) will
>fail if you've got less than three mon nodes and/or less than four
>storage nodes.  AIUI this restriction was deliberately put in place to
>discourage building tiny clusters :)
>> I know it's possible to run a Ceph cluster on a single node. Can DeepSea
>> do that kind of deployment right now? If not, what kind of modifications
>> would be needed?
>It might just be getting rid of those node count checks (or adding an
>option to skip them, which could be enabled when running tests?)
That is exactly right. Should be easy enough to include an option. On the other 
hand it is already possible if one would call the respective salt states 
individually instead of the orchestration file. Either way, that is also the 
only 'blocker' I see.
>> (The ability to deploy one- and two-node clusters would be useful for
>> DeepSea to have, since many teuthology test cases are designed to run on
>> such minimal configurations.)
>> If the whole thing could run on a single VM, that (in my mind) would
>> satisfy the definition of a unit test suite.
With a single VM we can run a basic test suite yes. Without having a particular 
example at the ready I think we might miss some features if we limit ourselves 
to one VM. Think everything that includes removing a node.
>If I'm right about the node count checks being the only thing to change,
>the minimum would probably be one VM, with one extra disk (or something
>that looks like a disk) to use for an OSD.
>> When Jenkins is triggered on a PR, it would create a VM in OpenStack,
>> git clone the branch/SHA1, run the test suite, get the result, and then
>> destroy the VM. The Jenkins machine could also be a VM in OpenStack.
>> Teuthology could be used as well, but not without significant
>> modifications. In my mind, unit testing should be kept as simple and
>> light-weight as possible. Teuthology does not fit into that mould.
>Tim Serong
>Senior Clustering Engineer
>tserong at suse.com
>Deepsea-users mailing list
>Deepsea-users at lists.suse.com

More information about the Deepsea-users mailing list