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+...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Friday, 13 January 2017 at 09:43 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev