Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C8139200D5B for ; Wed, 13 Dec 2017 13:59:32 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id C6D37160C23; Wed, 13 Dec 2017 12:59:32 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 18B8A160C16 for ; Wed, 13 Dec 2017 13:59:31 +0100 (CET) Received: (qmail 79691 invoked by uid 500); 13 Dec 2017 12:59:30 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 79665 invoked by uid 99); 13 Dec 2017 12:59:29 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Dec 2017 12:59:29 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 5C2C1C4A8B; Wed, 13 Dec 2017 12:59:29 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=6.31 tests=[none] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id vViOiSKh10no; Wed, 13 Dec 2017 12:59:27 +0000 (UTC) Received: from ns1.ngine.ch (ns1.ngine.ch [151.236.26.23]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 1B0A560EF9; Wed, 13 Dec 2017 12:56:18 +0000 (UTC) Received: from web01.ngine.ch (web01.ngine.ch [37.139.11.202]) by ns1.ngine.ch (Postfix) with ESMTP id C7C1C310F; Wed, 13 Dec 2017 13:56:13 +0100 (CET) Received: from [192.168.123.40] (109-60-239-77.dyn.cable.fcom.ch [77.239.60.109]) (Authenticated sender: mail@renemoser.net) by web01.ngine.ch (Postfix) with ESMTPSA id DA4D980A61; Wed, 13 Dec 2017 12:53:33 +0000 (UTC) Subject: Re: Call for participation: Issue triaging and PR review/testing To: dev , "users@cloudstack.apache.org" References: <3e09e6d6-05d6-b33a-b6ee-e4b64f9f665b@widodh.nl> From: Rene Moser Message-ID: Date: Wed, 13 Dec 2017 13:56:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit archived-at: Wed, 13 Dec 2017 12:59:33 -0000 Hi all On 12/13/2017 05:04 AM, Ivan Kudryavtsev wrote: > Hello, devs, users, Rohit. Have a good day. > > Rohit, you intend to freeze 4.11 on 8 january and, frankly speaking, I see > risks here. A major risk is that 4.10 is too buggy and it seems nobody uses > it actually right now in production because it's unusable, unfortunately, > so we are planning to freeze 4.11 which stands on untested 4.10 with a lot > of lacks still undiscovered and not reported. I believe it's a very > dangerous way to release one more release with bad quality. Actually, > marvin and units don't cover regressions I meet in 4.10. Ok, let's take a > look at new one our engineers found today in 4.10: So, the point is, how do we (users, devs, all) improve quality? Marvin is great for smoke testing but CloudStack is dealing with many infra vendor components, which are not covered by the tests. How can we detect flows not covered by marvin? For me, I decided (independent of this discussion) to write integration tests in a way one would not expect, not following the "happy path": Try to break CloudStack, to make a better CloudStack. Put a chaos monkey in your test infra: Shut down storage, kill a host, put latency on storage, disable network on hosts, make load on a host. read only fs on a cluster wide primary fs. shut down a VR, remove a VR. Things that can happen! Not surprisingly I use Ansible. It has an extensive amount of modules which can be used to battle prove anything of your infra. Ansible playbooks are fairly easy to write, even when you are not used to write code. I will share my works when ready. René