Open Stack

Hi Ken,

I am guessing the above "restart nodes" is for verifying each
> OpenStack service restarts successfully, right?

Yes, this is right. And we also will check that HA logic for these
services works correctly (for example, rescheduling of L3 Neutron
agents for networks).

But these service scripts are provided by distributors, and Devstack
> itself doesn't contain service scripts IIUC.
> So I'd like to know how to verify it on Devstack clouds.

Yes, DevStack doesn't support many scenarios which are actual
and should be supported on the production clouds.
It will be not possible to run all advanced test scenarios for DevStack
clouds,
just because DevStack can't deploy OpenStack cloud with 3 controllers
now (so, probably it will be possible in the future).

Of course, some advanced scenarios will support DevStack clouds,
for example, some test scenarios which are based on customer-found
issues from the real production clouds, like upload of the large images
(100+ Gb)
to Glance with Swift backend. Such cases are important for verification of
pre-production environments, but not very important for CI gate jobs.

It is also important to note that in these advanced cases we are targeting
to check not only the logic of Python code, but also the correct
configuration
of all OpenStack components on some pre-production OpenStack clusters.

Thank you!

On Wed, Sep 28, 2016 at 2:37 AM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
wrote:

> Hi Timur,
>
> Thanks for picking this up, that is interesting for me.
>
> 2016-09-22 5:58 GMT-07:00 Timur Nurlygayanov <tnurlygayanov at mirantis.com>:
> >
> > we have an idea to create the test suite with destructive/HA and advanced
> > end-user scenarios for the OpenStack clusters. This test suite will
> contains
> > advanced scenario integration tests for OpenStack clusters to make sure
> that
> > the cluster is ready for the production.
> >
> > The test cases which we want to cover in this test suite:
> > 1) All simple and advanced destructive actions, like a reboot of the
> nodes,
> > restart OpenStack services and etc. (we can probably use of-faults
> library
> > [1], which we already use in Rally)
> > 2) All advanced test scenarios like a migration of the bunch of VMs
> between
> > nodes and booting of the VMs with large images (10+ Gb), send traffic
> > between VMs and in parallel restart Neutron l3 agents and etc.
> >
> > The key requirements:
> > 1) The framework should know the details of the deployments (how many
> nodes
> > we have, how to ssh to OpenStack nodes, how to restart the nodes and
> etc.).
> > This is why we don't want to add such "advanced" and HA-focused test
> > scenarios to Tempest.
>
> Yeah, this point is right. This "advanced" way is different from the
> design principle of Tempest[1].
> I am guessing the above "restart nodes" is for verifying each
> OpenStack service restarts successfully, right?
> For productions(or distributions), this verifying point seems
> important because service scripts need to restart OpenStack services
> automatically.
> But these service scripts are provided by distributors, and Devstack
> itself doesn't contain service scripts IIUC.
> So I'd like to know how to verify it on Devstack clouds.
>
> Thanks
> Ken Ohmichi
> ---
>
> [1]: https://github.com/openstack/tempest#design-principles
>
> > 2) We should be ready to run these tests for any clouds: DevStack clouds
> (we
> > can skip HA cases for DevStack), Fuel clouds, clouds which were deployed
> by
> > Ansible or Puppet tools.
> > 3) This framework should allow reproduce the issue in a repeatable
> manner,
> > this is why we can't just cover all the tests with Rally load tests +
> > destructive plugins (we are working on this right now too to have an
> ability
> > to test HA-related scenarios under the load).
> >
> > As we discussed on the OpenStack summit a year ago it is better to move
> such
> > test suite in a separate repository and this framework can became a part
> of
> > the QA (or at least BigTent) program in OpenStack.
> >
> > I've created the commit to OpenStack project-config repository:
> > https://review.openstack.org/#/c/374667/
> >
> > Could you please take a look?
> >
> > We understand that it will be hard to add such test suite to the gates
> for
> > every commit in OpenStack because we will need a lot of hardware. We
> don't
> > want to add these tests to the per-commit gates for now, it is ok to run
> > them just once a day, for example. And we definitely need to have such
> test
> > suite to validate our own pre-production clouds.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Timur,
Senior QA Manager
OpenStack Projects
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160929/94da798e/attachment.html>