Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
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
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: 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
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
Hi Sean, I'm already working on something similar. What I'm trying to do is not a service, but a set of tests that would be able to run commands on the nodes and restart services, kill disks, etc. The basic idea is to inject some fault, see if everything still works as expected and restore the state back to what it was before the fault. So far I only have some basic tests for Swift, but I'm planning more. The state restoration is going to be via snapshots (so it will have to be running in VMs, or I could add support for LVM snapshots too) . The project is called DestroyStack and is located here: https://github.com/mkollaro/destroystack/tree/devel It's still WIP, please don't try to run it yet, not everything is implemented. I'm currently trying to create that demo. Martina On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote: Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: 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?
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
Good stuff. I like the semantics of what the destroy stack tests look like, very clean. I still think there would be value in doing this as a API service, which would let you decouple the test cases (and even put them in Tempest), as the tests could just assume certain fault semantics, and the implementation (which could even start with the ssh to nodes approach) would be left to the fault service. Do you think this would be an interesting evolution of destroystack, or is that different enough in goals that we should think about this problem separately. -Sean On 04/02/2014 08:55 AM, Martina Kollarova wrote: Hi Sean, I'm already working on something similar. What I'm trying to do is not a service, but a set of tests that would be able to run commands on the nodes and restart services, kill disks, etc. The basic idea is to inject some fault, see if everything still works as expected and restore the state back to what it was before the fault. So far I only have some basic tests for Swift, but I'm planning more. The state restoration is going to be via snapshots (so it will have to be running in VMs, or I could add support for LVM snapshots too) . The project is called DestroyStack and is located here: https://github.com/mkollaro/destroystack/tree/devel It's still WIP, please don't try to run it yet, not everything is implemented. I'm currently trying to create that demo. Martina On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote: Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: 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
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
On Wed 02 Apr 2014 03:38:18 PM CEST, Sean Dague wrote: Good stuff. I like the semantics of what the destroy stack tests look like, very clean. I still think there would be value in doing this as a API service, which would let you decouple the test cases (and even put them in Tempest), as the tests could just assume certain fault semantics, and the implementation (which could even start with the ssh to nodes approach) would be left to the fault service. This would still leave some problems that would make it difficult to add these tests into Tempest. First, to check if if some things are working beyond some basic yep, it sent back 200, you need access to the nodes. For example, when I'm testing Swift, I check if there are 3 replicas of each object by looking into the internals a bit - there is no API for this and I wouldn't trust it even if there was. Another problem would be test isolation - how would you do test clean-up in Tempest if you don't have access to the servers and cannot even start up a service? You would need a full OpenStack management service (could TripleO somehow do this?). But it would be interesting...the first implementation of Daas - Destruction as a Service. Martina Do you think this would be an interesting evolution of destroystack, or is that different enough in goals that we should think about this problem separately. -Sean On 04/02/2014 08:55 AM, Martina Kollarova wrote: Hi Sean, I'm already working on something similar. What I'm trying to do is not a service, but a set of tests that would be able to run commands on the nodes and restart services, kill disks, etc. The basic idea is to inject some fault, see if everything still works as expected and restore the state back to what it was before the fault. So far I only have some basic tests for Swift, but I'm planning more. The state restoration is going to be via snapshots (so it will have to be running in VMs, or I could add support for LVM snapshots too) . The project is called DestroyStack and is located here: https://github.com/mkollaro/destroystack/tree/devel It's still WIP, please don't try to run it yet, not everything is implemented. I'm currently trying to create that demo. Martina On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote: Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: 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,
[openstack-dev] [tempest][scenario] independece test between Stack and backing services?
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. 2) Stopping one or more OpenStack's processes. 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
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
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@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
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
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
