Please see my comments in-line. > -----Original Message----- > From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com] > Sent: 16 August 2016 07:33 > To: Yujun Zhang; TECH-DISCUSS OPNFV > Cc: Carlos Goncalves; dong.wenj...@zte.com.cn; Daniel Smith > (daniel.sm...@ericsson.com) > Subject: RE: ##freemail## [doctor][fuel] how to modify ceilometer > configuration for doctor testing > > If I understand it correctly, the major issue is that by default fuel > > installs ceilometer with no notifiers configured, i.e. `- notifier://` > > while doctor requires a topic setting i.e. `- > > notifier://?topic=alarm.all` > > Doctor team is not only one who need this config, but there could be other > users who need this config in order to use/provide event-alarm. Actually, > fuel seems to install aodh-listener, which is for event-alarm evaluation and > listens bus with topic=alarm.all, in default. Fuel, however, doesn't configure > event_pipeline.yaml of ceilometer correctly, so aodh-listener would be > hanging a silent message bus. This is certainly a bug in fuel. > > Apex had the same issue, but they already fixed it. > > In ceilometer project, we had a discussion that we shouldn't send notification > to aodh by setting this config *in default*, as it is different service, > although > is in the same telemetry umbrella. And, we left this config to an integrator > and a packager.
+1. > > Since there is no perfect way to resolve it, I would propose we choose > > a less risky way at the release window. What about we modify the > > configuration on the fly in doctor testing script and restore to origin when > the test is done. This could be considered as part of the preparation of > testing environment. > > +1 > > It should be easier to land. I do not agree with this approach. I am not going to repeat myself here again (please refer to my comments in Gerrit [1]). I will only add that activating the plugin only during doctor test scripts means we don't test for possible conflicts with other scenarios which may happen later on at production stage. OPNFV as software is supposed to deliver an integrated NFV platform. If we cannot even validate that OPNFV-enabled scenarios are functional and don't conflict among each other we are failing at fundamental key points (integration, testing and validation) we so much try to achieve and deliver. This is my personal view as things should be conducted and I would expect to see in any integrated open-source platform. In the end democracy should win, and I am only one of many Doctor contributors with +2 vote rights. [1] https://gerrit.opnfv.org/gerrit/18285 Thanks, Carlos _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
