Open Stack

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


-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140402/ff8b739a/attachment.pgp>