[openstack-dev] [tempest][scenario] independece test between Stack and backing services?

Tomoya Goto tomoya.goto at ctc-g.co.jp
Wed Apr 2 04:48:14 UTC 2014


Thanks for quick replies Igawa-san and Mr.Sean! :)
  and sorry foy my slow reply :(


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?

  - 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.

>>>   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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




More information about the OpenStack-dev mailing list