You should not push a branch to Gerrit, I usually use git review but you can also push directly to HEAD:refs/for/backtrace-T384539 (see https://gerrit.wikimedia.org/r/Documentation/user-upload.html#_git_push )

this is my current patch, FWIW

i tried to push a branch to gerrit but failed:

as you wish, will do

>>   @TheAnarcat  I agree the way the error was hidden is not ideal, but the stacktrace should have been logged into the cumin's logfile.
>>   Was this not the case?
>
> TIL: there's a logfile?

Yeah, ofc, see the related documentation <https://doc.wikimedia.org/cumin/master/configuration.html>, it's also mentioned in the help options:

  -d, --debug           Set log level to DEBUG. See also log_file in the configuration. [default: False]
  --trace               Set log level to TRACE, a custom logging level intended for development debugging. See also log_file in the configuration. [default:
                        False]

Is also a required config, cumin bails out if not set, so I'm pretty sure you have it :)

@TheAnarcat  I agree the way the error was hidden is not ideal, but the stacktrace should have been logged into the cumin's logfile.
Was this not the case?

Note that handling the exception itself is another question: the backend importer already has code to ignore import errors, but in this case the exception raised is not an ImportError, it's an AttributeError. maaaybe the code in grammar.py (_import_backend) could be changed to handle generic Exceptions instead... but i'm not sure that should be filed as a bug...

Why double? Curly braces don't need escape in the shell.

On a more detailed level: there will be at least one conflict in syntax I can think of right now, { and } can appear in both Cumin and Prometheus. I'm assuming the latter will need escaping (?)

Are you suggesting to keep the grammar super basic and let the user write any prometheus query?

hi! i've been looking into this again and I think i might start looking at making a backend for Prometheus myself. It seems the first step would be to design a grammar for the Prometheus queries that wouldn't conflict with the existing selectors.

whoohoo! thanks!

oh i hadn't noticed tests had failed... fixed that and the other comment, hopefully we're all done here.

ping - i think we need someone to review this...

would love to see this happen as well.. i've been banging my head against this trying to figure out why =true wouldn't work until I found this ticket. :) as a stopgap, documenting this limitation would be a good start...

right, so I think I understand your setup - you use HTTPS to talk to the PuppetDB from various hosts and probably use something like IP-level blocking to ensure data integrity. that's fine and it's what we do for other stuff like monitoring (Prometheus) here as well. i just don't see why i should absolutely get a valid certificate to talk to the PuppetDB if I have authentication and privacy figured out some other way.

patch now lives in https://gerrit.wikimedia.org/r/#/c/operations/software/cumin/+/497312 - let me know if i should expand it to cover ~/.config discovery and so on.

hi @Volans ! long time no see ;)

I did - as you can see, in the last command:

i managed to login to gerrit, but couldn't figure out how to push my patch for review:

As an extension to this, it would perhaps be necessary for Cumin to look in standards directories, like ~/.config/ (or maybe ~/.config/cumin) for its configuration file, otherwise root is still required to edit things in /etc/cumin/...