+1 for this!

Add test.

Ready for review.

+1 here, I will wait for the Monday if qwan wants to review that. Feel free to merge on Monday :)

This looks not so reasonable, can we just use something like ZMQ_ENABLED and STOMP_ENABLED to enable/disable connecting to zmq and stomp endpoints?

I think it's unnecessary to change the parsers & handlers in this way, when you need to disable//enable some of the parsers/handlers, you can just edit the config options directly.

I'd prefer to just use PARSERS.

Same as above, we can edit this option directly rather than by checking a variable.

something like:
if ZMQ_ENABLED and STOMP_ENABLED:
# raise error if we can't support enabling ZMQ and STOMP in the same time.
if ZMQ_ENABLED:
# ZMQ specific options
if STOMP_ENABLED:
# STOMP specific options.

I think we need to support specifying the options in config rather than only support getting them from os.environ.

I guess you mean freshmaker's config. How to read freshmaker's config from this file?

Reading these stomp configuration from a config file could be good, but, how much extra benefit to freshmaker in practice?

This file should be read by fedmsg (or probably the fedmsg-hub, I'm not sure) to configure itself. Using environment variables is a convenient way during development normally. It could also be used to configure freshmaker when deploy and run in a server, but in practice, these stomp_* options should be replaced with real value by some deployment scripts, e.g. ansible playbook.

Whatever the way to read options from freshmaker config file, this file is a fedmsg-hub configuration file, I think it is not a good idea to introduce a dependency between fedmsg-hub and freshmaker in the aspect of configuration.

This fedmsg.d/freshmaker.py is just the config I mean, which we'll put it under /etc/fedmsg.d while deploying, yes it's easy to have the variables configured with ansible scripts, but it's not a good idea to assume we will always use ansible for deploying. It's good to have it be configurable via environment variables, but not good to unable to configure in this config file.

Sorry, the comments are for the change in fedmsg.d/freshmaker.py. In my opinion, RH_MODE and FRESHMAKER_INSIDE_RH can just be removed. it makes sense to just update MESSAGING_TOPIC_PREFIX, HANDLERS and PARSERS directly in this config when necessary.

We would then need to have two config.py files in the repository, one for RH and one for Fedora. I don't want to configure all the fields in config.py to have Freshmaker working on Fedora/RH when I need to test something :).

Separate config file for RH is my original thought. However, a bug in init_config need to fix in advance, that is freshmaker does not load and read config from FRESHMAKER_CONFIG_FILE when specify FRESHMAKER_DEVELOPER_ENV.

What's your opinion on renaming this to just PARSERS?

Compare to config.py, the difference is configuring message topic and disable/enable some handlers/parsers, I personally think it's easy to just update conf/config.py when you need to deploy Freshmaker in different env, I'm wondering does it worth to add another config file for this case.

And I'd suggest squash the 2 commits since the second one is just reverting the changes in the first one with minor updates.

Commits are squashed. EVENT_PARSERS is renamed to PARSERS.

What's your opinion on renaming this to just PARSERS?

It's ok. Have renamed it.

+1, @qwan, can you also check it?

+1