seeing invalid JSON format from default config example

[shus2018]

example should be in correct JSON format in case.

Traceback (most recent call last): File "/local1/miniconda3/bin/crossbar", line 11, in sys.exit(run()) File "/local1/miniconda3/lib/python3.6/site-packages/crossbar/controller/cli.py", line 1178, in run options.func(options, reactor=reactor) --- --- File "/local1/miniconda3/lib/python3.6/site-packages/crossbar/controller/cli.py", line 695, in run_command_start node.load(options.config) File "/local1/miniconda3/lib/python3.6/site-packages/crossbar/controller/node.py", line 460, in load self._config = checkconfig.check_config_file(configpath, self._native_workers) File "/local1/miniconda3/lib/python3.6/site-packages/crossbar/common/checkconfig.py", line 3166, in check_config_file raise InvalidConfigException("configuration file does not seem to be proper JSON ('{}')".format(e)) crossbar.common.checkconfig.InvalidConfigException: configuration file does not seem to be proper JSON ('Expecting ',' delimiter: line 142 column 1 (char 6234)')

[chrisbarber]

This seems to be the error produced when trying to run crossbar with .crossbar/config.json.j2 renamed as a *.json file, but without having run it through jinja processing. We were seeing this on idatacube when the xrelease ansible script was trying to render the config template on the target machine (my mistake); apparently rather than failing the step it was just copying the template to .crossbar/config.json without doing any rendering. This PR addresses that, along with my changes to the datacube bamboo builds which render the template into the artifacts so it is already present when deploying.

You'll need to avoid using ansible to try to render the template on the target host since it does not work. You'll also need to get a config rendered for DATACUBE_ENV=test. I only have bamboo builds set up for dev and production right now. I could theoretically generate all three configs in all artifacts, but I like that only the appropriate config is available in its corresponding artifact, so there is less possibility for accidentally using the config for the wrong environment.

This is how I render the config in the bamboo build:

conda activate
pip install yasha
yasha .crossbar/config.json.j2 -o .crossbar/config-$DATACUBE_ENV.json
conda deactivate

(This installs yasha into the root conda environment, so it doesn't pollute the datacube conda environment. Another environment could be substituted.)

I am thinking about modifying the branching strategy and bamboo builds so that:

1. dev branch has DATACUBE_ENV=dev
2. release branch has DATACUBE_ENV=test
3. master branch has DATACUBE_ENV=production

As opposed to the current setup which is:

1. dev branch has DATACUBE_ENV=dev
2. release branch has DATACUBE_ENV=production (but is also used by test)
3. master branch is unused

I'll have to think about this for a while, but it would simplify things as there would then be build artifacts available for every stage, making it more consistent and making it unnecessary to render the config as part of the deployment process for test.

[shus2018]

Thanks, Chris. Good to know we have generated a good copy. By the way, I did work around this weekend manually. I can copy the generated config-production.json or update deployment scripts to use config-production.json instead of old way config-prod.json. :-)

[chrisbarber]

Okay. Ideally test would use config-test.json but like I was saying that is not being pre-generated by any bamboo builds yet.

I'll leave this issue open in case I decide to create another bamboo build to generate artifacts for test.