Switch to using the package provided by Azure Functions to set up Application Insights.
Using the provided setup method `AddApplicationInsightsTelemetry` will configure the dependency collector by default as well as set up some other things that we haven’t done manually, including application version, which would be very useful.
This also means that `operation_Id` is populated more consistently which permits joining `traces` or `dependencies` on the `requests` table.
This also means that the end-to-end data in AI is now correct, so the chart works:
* Remove one GET from ListInstanceIds
* Only invoke ListInstanceIds if needed
* Format code
* Downgrade Exception log to Verbose
* Insert InstanceID during CleanupNodes
Co-authored-by: Cheick Keita <chkeita@microsoft.com>
Node.js 12 actions are deprecated, as well as `::set-output`
- Update `actions/checkout` to v3
- Update `actions/upload-artifact` to v3
- Update `actions/setup-python` to v4
- Update `actions/cache` to v3
- `set-output` on stdout is deprecated, update to `$GITHOUT_OUTPUT` method
- Change from `actions-rs/toolchain` (unsupported) to `dtolnay/rust-toolchain`
The only warning remaining after this is the one about Ubuntu 18.04.
1. `ListVmss` was invoking `GetVirtualMachineScaleSetAsync` and then `GetVirtualMachineScaleSetVms`; instead we can get the VMSS resource directly and invoke `GetVirtualMachineScaleSetVms` on it.
2. I also removed some unneeded invocations of `AsAsyncEnumerable` which might be turning async enumerables into sync enumerables.
3. Do the same `HasData` check in the instance ID lookup that we were already doing in `ListVmss`.
After this change (#3) we no longer do any `GET`s against individual VMSS VMs during the `check-pr` run:
Addressing #2550 but in a slightly different way:
1. Always include the machine name in the agent registration message. From the machine name we can extract the instance ID.
2. Use the stored value in preference to fetching it every time.
3. To back-fill existing nodes that do not have the value stored, update it in AcquireScaleInProtection if it is not already present.
* .
* 🧹
* Do backoff on main queue, kick off to poison queue after sufficient retries
* PR comments
Co-authored-by: Teo Voinea <Teodor.Voinea@microsoft.com>
As of #2529 we now fail if the coverage recording times out. The default timeout (5s) does not appear to be long enough for even simple tasks to run, so extend it to 120s.
* 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>
