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

Weyl, Alexey (Nokia - IL) alexey.weyl at nokia.com
Tue Nov 15 12:40:51 UTC 2016

Ok, sounds good.

We need to understand what is the common way in openstack to work with deprecated code.

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

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.weyl at 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.

More information about the OpenStack-dev mailing list