Open Stack

Hi Yujun,

The motivation in building the mocks this way was that we could easily generate a series of events which are different from one another. There used to be a distinction between ‘static fields’ and ‘dynamic fileds’, and a library named exrex was used to generate random values by regex definitions (e.g. "instance-[0-9]{7}"). We were then contacted by the infra team that exrex was not a known library in OpenStack (did not appear in global-requirements), and we decided to remove it. You can still see in the code leftovers from the old implementation.

I’m not sure if all datasources need the ability to generate a series of events. But since this is the way it was built, I decided to keep the structure in the Doctor datasourcde that I’ve recently written.

I’ll be happy to also hear Elisha’s opinion about it, as he created this mechanism.

Best Regards,
Ifat.


From: Yujun Zhang <zhangyujun+zte at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Friday, 13 January 2017 at 09:43
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [vitrage] code organization for trace generator and

Hi, Root Causers

In the implementation of static driver unit test, the most difficult part I've encountered is the mock driver and trace generator.

Is there any particular reason to put all mock driver and transformer specs in the same file `trace_generator.py` and `mock_driver.py`? Would it be easier to maintain and extend if we organize the specs and drivers in datasource, e.g. `mock.static`, `mock.nova.host` and etc?

--
Yujun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170115/bdac97cc/attachment.html>