I agree. We should track this issue in JIRA. Which project shall we put it in? Pharos?
Besides the configuration harmonization, we have also spotted some performance deviation between environments deployed by different installers. Theoretically , a consistent environment should be targeted no matter which installer user has chosen. -- Yujun On Tue, Sep 6, 2016 at 11:52 PM SULLIVAN, BRYAN L <[email protected]> wrote: > 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:* [email protected] [mailto: > [email protected]] *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 > > [email protected] > > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > > > -- > > Jack Morgan > > OPNFV Pharos Intel Lab > > _______________________________________________ > opnfv-tsc mailing list > [email protected] > https://lists.opnfv.org/mailman/listinfo/opnfv-tsc >
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
