* Handle nulls better
* Populate data if it's not
* fmt
* Fix bug where scaleset won't go to 0
Co-authored-by: Teo Voinea <Teodor.Voinea@microsoft.com>
* Fix bug where field key is not serialized properly
* Log if we match multiple active WIs, re-open if we only find duplicates
* Wrap up testing
* Update naming to clarify duplicates are talking about work items, not notification config
Co-authored-by: Teo Voinea <Teodor.Voinea@microsoft.com>
To comply with Microsoft security policies, we must use only approved crypto libraries.
Notably, `ring` is not on the approved libraries list. We should use the platform crypto libraries instead. The official guidance is:
- on Windows, schannel and friends
- on Linux, the OpenSSL 1.1.1 series if available, otherwise OpenSSL 3.0. OpenSSL _must_ be dynamically and not statically linked so that distro-provided updates can be used.
Following these guidelines strictly would mean that we have to build distro/version specific binaries for Linux. Instead we have an exception which allows us to statically link against the OpenSSL 1.1.1 series, allowing us to have a (somewhat) portable binary.
OpenSSL 1.1.1. can be statically linked by switching to the `native-tls-vendored` feature of `reqwest`. (Verified by inspection that `ring` and `rustls` are no longer in `Cargo.lock` files.)
So the result is:
- on Windows, we use schannel
- on Linux we statically link against 1.1.1
It is up to us to ensure we keep up-to-date with OpenSSL issues and releases. The version can be checked by looking at the version of `openssl-src` that we depend upon. Currently this is `111.22.0+1.1.1q`. This is the latest version; also check the [Vulnerabilities page](https://www.openssl.org/news/vulnerabilities-1.1.1.html).
---
Verified by inspection that `rustls` and `ring` are no longer present in `Cargo.lock`.
Current dynamic library dependencies are:
```console
$ ldd ./onefuzz-agent
linux-vdso.so.1 (0x00007ffd9ba60000)
libunwind.so.8 => /lib/x86_64-linux-gnu/libunwind.so.8 (0x00007ff5ab5e5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff5ac1d1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff5ac1cc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff5ab4fe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff5ac1c7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5ab2d4000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff5ac1dc000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007ff5ab2a9000)
```
Closes#2520.
After investigation the underlying cause here is that the process is getting killed due to timeout, but we don't report the timeout or produce an error. Modify the coverage code so that it fails if timeout is hit.
* Add SrcView::try_insert function
* Make try_insert return bool indicating success
* Rustfmt
* Set test to be ignored (no compile)
* Bump srcview version
Co-authored-by: Sutton Bradley <suttonb@microsoft.com>
Co-authored-by: George Pollard <gpollard@microsoft.com>
* add more logs
* bug fix
* more logs
* another fix
* fix integration tests
* do not log error when vm deletion is in progress
* addressing comments
* .
* ..
Co-authored-by: stas <statis@microsoft.com>
* Cache VMSS VM InstanceID lookups
* Adding an expiration time to the cache
* make the TTL 10 min
* properly add entries to the cache
Co-authored-by: Cheick Keita <chkeita@microsoft.com>
During `TimerWorkers` if updating one entity fails and throws an exception we will abandon the whole update. Instead log the error and continue to attempt to process the remaining entities. This will allow us to make progress even if one entity is stuck.
In our integration test run we are seeing some connection-reset errors which causes the CLI operation to fail.
To fix this:
1. Set TCP-KeepAlive to keep Azure load balancer connections alive longer than the default timeout (4 minutes).
2. Treat ConnectionResetError as retryable.
