* Upgrade create-react-app to v5
Some other dependencies needs to be upgraded as well, plus some typescript errors fixed.
Signed-off-by: Łukasz Mierzwa <l.mierzwa@gmail.com>
* Use ESM imports for codemirror-promql
Signed-off-by: Łukasz Mierzwa <l.mierzwa@gmail.com>
* Update FontAwesome to v6
Signed-off-by: Łukasz Mierzwa <l.mierzwa@gmail.com>
* Run gofumpt on all files
Getting golangci-lint errors when building on my laptop, possibly because I have newer version of gofumpt then what it was formatted with.
Run gofumpt -w -extra on all files as it will be needed in the future anyway.
* Update golangci-lint to v1.44.2
v1.44.0 upgraded gofumpt so bumping version in CI will help keep formatting correct for everyone
* Address golangci-lint error
Getting 'error-strings: error strings should not be capitalized or end with punctuation or a newline' from revive here.
Drop new line.
Signed-off-by: Łukasz Mierzwa <l.mierzwa@gmail.com>
* Simplify code by letting common deal with empty TLS config
* Improve error message if we notice a user is putting an authorization
header into its configuration.
Signed-off-by: Julien Pivotto <roidelapluie@inuits.eu>
The upgraded client adds order=creation_date_desc to the query
parameters causing the tests to fail. Instead of checking the full URI,
just check that the path is correct.
Signed-off-by: Chris Marchbanks <csmarchbanks@gmail.com>
The k8s dependencies have been manually updated to the most recent
0.22.x release due to 0.23.x requiring go 1.17.
Signed-off-by: Chris Marchbanks <csmarchbanks@gmail.com>
* Improve error logging for missing config and QL dir
Currently, when Prometheus can't open its config file or the query
logging dir under the data dir, it only logs what it has been given
default or commandline/config. Depending on the environment this can be
less than helpful, since the working directory may be unclear to the
user. I have specifically kept the existing error messages as intact as
possible to a) still log the parameter as given and b) cause as little
disruption for log-parsers/-analyzers as possible.
So in case of the config file or the data dir being non-absolute paths,
I use os.GetWd to find the working dir and assemble an absolute path for
error logging purposes. If GetWd fails, we just log "unknown", as
recovering from an error there would be very complex measure, likely not
worth the code/effort.
Example errors:
```
$ ./prometheus
ts=2022-02-06T16:00:53.034Z caller=main.go:445 level=error msg="Error loading config (--config.file=prometheus.yml)" fullpath=/home/klausman/src/prometheus/prometheus.yml err="open prometheus.yml: no such file or directory"
$ touch prometheus.yml
$ ./prometheus
[...]
ts=2022-02-06T16:01:00.992Z caller=query_logger.go:99 level=error component=activeQueryTracker msg="Error opening query log file" file=data/queries.active fullpath=/home/klausman/src/prometheus/data/queries.active err="open data/queries.active: permission denied"
panic: Unable to create mmap-ed active query log
[...]
$
```
Signed-off-by: Tobias Klausmann <klausman@schwarzvogel.de>
* Replace our own logic with just using filepath.Abs()
Signed-off-by: Tobias Klausmann <klausman@schwarzvogel.de>
* Further simplification
Signed-off-by: Tobias Klausmann <klausman@schwarzvogel.de>
* Review edits
Signed-off-by: Tobias Klausmann <klausman@schwarzvogel.de>
* Review edits
Signed-off-by: Tobias Klausmann <klausman@schwarzvogel.de>
* Review edits
Signed-off-by: Tobias Klausmann <klausman@schwarzvogel.de>
There is the critical CVE-2021-43816 against containerd which is only
fixed in v1.5.9. In practice I don't believe this affects prometheus.
However, upgrading will help quieten loud vulnerability scanners.
To upgrade I ran go get github.com/containerd/containerd@v1.5.9.
Signed-off-by: Keegan Carruthers-Smith <keegan.csmith@gmail.com>
If a queue is stopped and one of its shards happens to hit the
batch_send_deadline at the same time a deadlock can occur where stop
holds the mutex and will not release it until the send is finished, but
the send needs the mutex to retrieve the most recent batch. This is
fixed by using a second mutex just for writing.
In addition, the test I wrote exposed a case where during shutdown a
batch could be sent twice due to concurrent calls to queue.Batch() and
queue.FlushAndShutdown(). Protect these with a mutex as well.
Signed-off-by: Chris Marchbanks <csmarchbanks@gmail.com>