Hello, Igawa-san

Thanks for pointing out Tempest principles. I wasn't aware of them.

ok, I'll probably use the current test cases with manually stopping services. I'm checking with Temest(icehouse) and if I write or think up something useful, I'll be back. Also Grenade, too. :)


Thank you  for valuable advices,
        - Tomoya Goto



Hi,

On 04/02, Tomoya Goto wrote:
Thanks for quick replies Igawa-san and Mr.Sean! :)
  and sorry foy my slow reply :(

np :)



The task I wantetd to conduct is not only for upgrading but also for
rather small maintenace, say stopping openstack-cinder* for changing
configuration.

Now, Grenade is for upgrade purpose but not for such small
maintenace, right?
So I think tempest is more suitable than Grenade for such task.

what do you say?

This kind (fault injection?) of tests that you said are interesting and
we should have them in future. But Tempest should not operate OpenStack
components directly. e.g. stop/start Cinder/Glance/Nova services.
This is one of design principles[1]. So I think we need a new project
for these types of tests or need to change the principles.

[1] http://docs.openstack.org/developer/tempest/overview.html#design-principles

Thanks,
-- Masayuki Igawa


  - Tomoya Goto


You are correct. The testing we do for this is in Grenade, which we run
in the gate. Grenade tests an upgrade from last stable release to
current master. It creates a few resources before the upgrade, and fails
if those are interupted after the upgrade.

Grenade is still pretty light on the number of resources it creates
before the upgrade, and is definitely a place where enhancement is welcome.

        -Sean


On 04/01/2014 04:18 AM, Masayuki Igawa wrote:
Hi Goto-san,

I think this is an interesting test case. But AFAIK, Tempest and its
scenario tests don't have such test cases now, and we can't stop the
OpenStack processes through Tempest.

Do you know Grenade[1]? I think Grenade is the only one upgrading test in
the OpenStack community now. So I guess Grenade can test these kind of
tests but not yet though.

[1] https://wiki.openstack.org/wiki/Grenade


On 04/01, 後藤 僚哉 wrote:
Hello everyone.

I'm looking for an independence test between an OpenStack environment
and virtual environments.

In case of updating an openstack environment, you need to stop each
OpenStack process, but you don't want the instances to be affected by
OpenStack outages.
So before maintenane, you want to make sure OpenStack and backing
services(KVM, OVS, storage,.) are separate.

For example.
  1) Creating a virtual environment on a OpenStack environment. this
includes Nova instances, Neutron L2/3 networks, Cinder volumes and etc.

I'd like to clarify more. Do you mean OpenStack on OpenStack environment?
Or just mean VMs on OpenStack env?

I meant just VMs on OpenStack env.
When you stop some processes for update, say openstack-cinder-*, you
want to make sure it won't disconnect volume/VM.

Thanks, I got it.


  2) Stopping one or more OpenStack's processes.

Currently, Tempest can't stop the OpenStack processes. Because Tempest
can operate OpenStack components through OpenStack APIs only for now.
oh yes. Just like I feard.


Thanks,
-- Masayuki Igawa

  3) Running this test, and checking that each resource doesn't stop.
  4) Updating an OpenStack, editing configurations or etc.
I assume such test is coverd by tempest.

Dose Tempest have those test methods? or if not, do you think it's going
to be handy if I make such test?


Best regards,
Tomoya Goto

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to