Open Stack

Mark,

The major constraint here is gate memory (which is maxed at 8gb).  This is barely enough to run compute-kit (which is tested).  Now that multiple nodes are a thing, it may be possible to run computekit on one node, and other services on other nodes.  (IOW the environment has changed, and may be more conducive to adding more gating).

Cheers
-steve

From: Mark Goddard <mark at stackhpc.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Monday, April 30, 2018 at 4:34 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Zun][Kolla][Kolla-ansible] Verify Zun deployment in Kolla gate

Hi,

This is something I've been thinking about recently. In particular, I noticed a patch go by to fix the same issue in the magnum role that has been broken and fixed previously. Kolla needs to up its game in terms of CI testing.

At the very least, we need tests that verify that services can be deployed. Even if we don't verify that the deployed service is functional, this will be an improvement from where we are today.

As with many things, we won't get there in a single leap, but should look to incrementally improve test coverage, perhaps with a set of milestones spanning multiple releases.

I suggest our first step should be to add a set of experimental jobs for testing particular services. These would not run against every patch, but could be invoked on demand by commenting 'check experimental' on a patch in Gerrit. For many services this could be done simply by setting 'enable_<service>=true' in config.

There are many paths we could take from there, but perhaps this would be best discussed at the next PTG?

Cheers,
Mark

On Mon, 30 Apr 2018, 14:07 Jeffrey Zhang, <zhang.lei.fly at gmail.com<mailto:zhang.lei.fly at gmail.com>> wrote:
Thanks hongbin

In Kolla, one job is used to test multi OpenStack services. there are already two test scenarios.

1. without ceph
2. with ceph

each scenario test a serial of OpenStack services. like nova, neutron, cinder etc.
Zun or kuryr is not tested now.  But i think it is OK to add a new scenario to test network related
service, like zun and kuryr.

for tempest testing, there is a WIP bp for this[0]

[0] https://blueprints.launchpad.net/kolla-ansible/+spec/tempest-gate

On Sun, Apr 29, 2018 at 5:14 AM, Hongbin Lu <hongbin034 at gmail.com<mailto:hongbin034 at gmail.com>> wrote:
Hi Kolla team,

Recently, I saw there are users who tried to install Zun by using Kolla-ansible and reported bugs to us whenever they ran into issues (e.g. https://bugs.launchpad.net/kolla-ansible/+bug/1766151). The increase of this usage pattern (Kolla + Zun) made me think that we need to have CI coverage to verify the Zun deployment setup by Kolla.

IMHO, the ideal CI workflow should be:

* Create a VM with different distros (i.e. Ubuntu, CentOS).
* Use Kolla-ansible to stand up a Zun deployment.
* Run Zun's tempest test suit [1] against the deployment.

My question for Kolla team is if it is reasonable to setup a Zuul job as described above? or such CI jobs already exist? If not, how to create one?

[1] https://github.com/openstack/zun-tempest-plugin

Best regards,
Hongbin

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<http://xcodest.me/>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180501/c714e2b1/attachment-0001.html>