Re: [openstack-dev] [vitrage] code organization for trace generator and
I heard the exrex story from Elisha, though I didn't quite understand the
rule of allowed library in OpenStack.
I have also kept it in static datasource, but it was not so convenient to
jump over these long files to find the static datasource related function
On Sun, Jan 15, 2017 at 5:24 PM Afek, Ifat (Nokia - IL) <ifat.a...@nokia.com>
wrote:
> 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
>
__
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
Re: [openstack-dev] [vitrage] code organization for trace generator and
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
[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
