Re: [openstack-dev] [ALU] [vitrage] bp:static-datasource-config-formatworking items

2016-11-15 Thread Yujun Zhang
Hi, Alexey

I plan to split the implementation to several steps, because it will take
weeks to complete. I'm afraid it would be too big a patch to review if I
submit all changes in one patch set.

Instead I want to get comments as earlier as possible. Each submit will be
covered by additional unit test and keep backward compatibility.

Detail replies inline.

On Tue, Nov 15, 2016 at 5:51 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
> Good job! This is a very important change for Vitrage.
>
> I have a couple of questions please:
> 1. Why do we want to create a new datasource ‘static’ and not rename the
> current ‘static_physical’ datasource and change it to work with the new
> format?
>
I don't want to break it during the evolution.

> 2. How are you planning to use the old 'static_physical' datasource  as a
> proxy if you said that you want to remove it?
>
Good point. Any suggestion on how we hide the deprecated modules? Move it
as a submodule in new module.

> 3. What kind of merge is needed in the evaluator?
>
Parsing of `definition` section would be a common module for both evaluator
and static data source

> 4. I saw the implementation of the driver.py in static, and it doesn't do
> anything at the moment? (if you are still working on one of the patches
> then please market it as -1 in the code-review that we will know that you
> are still working on it.
>
Yes, skeleton is skeleton. Since I'm working remotely with vitrage team. I
want to keep you updated on the progress. Still, it is complete with unit
test and backward compatibility and will reduce further review work.
__
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] [ALU] [vitrage] bp:static-datasource-config-formatworking items

2016-11-15 Thread Weyl, Alexey (Nokia - IL)
Hi Yujun,

Good job! This is a very important change for Vitrage.

I have a couple of questions please:
1. Why do we want to create a new datasource ‘static’ and not rename the 
current ‘static_physical’ datasource and change it to work with the new format?
2. How are you planning to use the old 'static_physical' datasource  as a proxy 
if you said that you want to remove it?
3. What kind of merge is needed in the evaluator?
4. I saw the implementation of the driver.py in static, and it doesn't do 
anything at the moment? (if you are still working on one of the patches then 
please market it as -1 in the code-review that we will know that you are still 
working on it.)

BR,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Tuesday, November 15, 2016 9:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] 
bp:static-datasource-config-formatworking items

Hi folks.

I have just started working on the blueprint about static datasource config 
format[1]. The planned working items are as following.
1. create new datasource `static` to parse new configuration format
2. parse old configuration format in `static` with a proxy to existing 
`static_physical` module
3. remove `static_physical` datasource and print deprecation warning in `static`
4. merge common logic with scenario template evaluator
Requesting for comments.

P.S. I chose the name `static` since it is actually not limited to physical 
entities. Virtual entities can also be described in `static` file if there is 
no dynamic source.

[1]: 
https://blueprints.launchpad.net/vitrage/+spec/static-datasource-config-format

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