I’d suggest a Jira issue be created that we can add details to. I agree that this will be a very helpful effort. Right now there is substantial variation in the deployed platform e.g. even to such things as:
- Number and names of networks, routers, etc created by default - Default images created in glance - Names of projects (e.g. “services” vs “service”) - … These variations add complexity to install and test scripts for features. As we eliminate the variations, we do need a process to identify and address impact to existing code and tests. Thanks, Bryan Sullivan | AT&T From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jack Morgan Sent: Tuesday, September 06, 2016 8:41 AM To: TSC OPNFV Cc: TECH-DISCUSS OPNFV Subject: Re: [opnfv-tech-discuss] harmonized configuration set for OPNFV Yujun, Thanks for raising this issue. This is a longer term issue to solve but for now I've added it as a topic for to the Infra WG weekly meeting. I'm hoping to solve this for the D release and been tasked by the TSC to help drive this effort. Please join the Infra WG meeting to provide your input. On 09/05/2016 12:11 AM, Yujun Zhang wrote: Dear TSC, We have encountered some issues on the openstack environment configuration for some projects and it could not be resolved within the project scope. So I have to escalate it to TSC to look for a solution. Some OPNFV project requires dedicated configuration on common services. But the environment deployed by the installers may not always come with a valid configuration. For example, doctor project requires `notifier://?topic=alarm.all` in ceilometer event pipeline configuration. But the default deployed environment by fuel does not include this configuration. There has been a long debates between the two teams on where the modification should be made [1][2]. The contradiction is that if we enable this notifier topic, doctor will work, but nobody can guarantee that other projects are not affected. OPNFV is targeting to deliver a "de facto standard open source NFV platform for the industry" [3]. The platform on software part includes not only the services installed but also a common configuration for all projects to run. So the first step should be working out a harmonized configuration set which will allow all existing projects to run normally. Then it can be used to validate the deployed environment from each installer. I'm sincerely hoping TSC can help to resolve this issue and lead OPNFV to a success. [1] https://gerrit.opnfv.org/gerrit/#/c/18285/ [2] https://jira.opnfv.org/browse/FUEL-159 [3] https://wiki.opnfv.org/ -- Yujun Zhang _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss -- Jack Morgan OPNFV Pharos Intel Lab
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
