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