Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config parser does not complain about overriden parts of configuration #1275

Closed
RichiH opened this issue Dec 28, 2015 · 3 comments · Fixed by #4033
Closed

Config parser does not complain about overriden parts of configuration #1275

RichiH opened this issue Dec 28, 2015 · 3 comments · Fixed by #4033

Comments

@RichiH
Copy link
Member

RichiH commented Dec 28, 2015

While I readily agree that autogenerated config files should not have this problem, and that YAML works that way, especially in the trial phase, this can confuse users. Warning or, preferably, erroring out would be appreciated.

If you run with a configuration like:

scrape_configs:
  - job_name: 'prometheus_system'
    target_groups:
    - targets: ['localhost:9100']

scrape_configs:
  - job_name: 'foo_system'
    target_groups:
    - targets: ['foot:9100']

the former scrape_configs is silently discarded. While that's the obvious case, constructs like

scrape_configs:
  - job_name: 'prometheus_system'
    target_groups:
    - targets: ['localhost:9100']

rule_files:
  - 'prometheus.rules'

scrape_configs:
  - job_name: 'foo_system'
    target_groups:
    - targets: ['foo:9100']

are silently discarded as well.

So to summarize: Yes, I fat-fingered, but principle of least surprise would be to error out instead of silently carrying on.

@fabxc
Copy link
Contributor

fabxc commented Dec 28, 2015

Unfortunately, that is an issue of the YAML parser package. Detecting this in a clean way in Prometheus is not really an option.

If no error is thrown, the YAML spec would actually require any subsequent occurrences to be discarded rather then the previous ones (http://yaml.org/spec/1.1/#id932806).

I agree that it's annoying and an error message would be nice to have. But it's not enough of a problem to introduce silly hacks to the Prometheus code base to work around a bug in an upstream package (for which there's not alternative).

@RichiH
Copy link
Member Author

RichiH commented Dec 28, 2015

Closing as per IRC.

Created go-yaml/yaml#154 instead.

@lock
Copy link

lock bot commented Mar 24, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Mar 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants