Merge branch 'support-bundles-crdb' into support-bundle-bg-task

.config/nextest.toml

@@ -3,7 +3,7 @@
 #
 # The required version should be bumped up if we need new features, performance
 # improvements or bugfixes that are present in newer versions of nextest.
-nextest-version = { required = "0.9.77", recommended = "0.9.78" }
+nextest-version = { required = "0.9.77", recommended = "0.9.86" }
 
 experimental = ["setup-scripts"]
 

.github/buildomat/build-and-test.sh

@@ -18,7 +18,7 @@ target_os=$1
 # NOTE: This version should be in sync with the recommended version in
 # .config/nextest.toml. (Maybe build an automated way to pull the recommended
 # version in the future.)
-NEXTEST_VERSION='0.9.78'
+NEXTEST_VERSION='0.9.86'
 
 cargo --version
 rustc --version
@@ -69,7 +69,8 @@ banner ls-apis
     source ./tools/include/force-git-over-https.sh;
     ptime -m cargo xtask ls-apis apis &&
         ptime -m cargo xtask ls-apis deployment-units &&
-        ptime -m cargo xtask ls-apis servers
+        ptime -m cargo xtask ls-apis servers &&
+        ptime -m cargo xtask ls-apis check
 )
 
 #

Cargo.toml

@@ -108,6 +108,7 @@ members = [
     "sled-agent/bootstrap-agent-api",
     "sled-agent/repo-depot-api",
     "sled-agent/types",
+    "sled-diagnostics",
     "sled-hardware",
     "sled-hardware/types",
     "sled-storage",
@@ -240,6 +241,7 @@ default-members = [
     "sled-agent/bootstrap-agent-api",
     "sled-agent/repo-depot-api",
     "sled-agent/types",
+    "sled-diagnostics",
     "sled-hardware",
     "sled-hardware/types",
     "sled-storage",
@@ -361,7 +363,7 @@ derive_more = "0.99.18"
 derive-where = "1.2.7"
 # Having the i-implement-... feature here makes diesel go away from the workspace-hack
 diesel = { version = "2.2.4", features = ["i-implement-a-third-party-backend-and-opt-into-breaking-changes", "postgres", "r2d2", "chrono", "serde_json", "network-address", "uuid"] }
-diesel-dtrace = "0.4.0"
+diesel-dtrace = "0.4.2"
 dns-server = { path = "dns-server" }
 dns-server-api = { path = "dns-server-api" }
 dns-service-client = { path = "clients/dns-service-client" }
@@ -596,6 +598,7 @@ sled = "=0.34.7"
 sled-agent-api = { path = "sled-agent/api" }
 sled-agent-client = { path = "clients/sled-agent-client" }
 sled-agent-types = { path = "sled-agent/types" }
+sled-diagnostics = { path = "sled-diagnostics" }
 sled-hardware = { path = "sled-hardware" }
 sled-hardware-types = { path = "sled-hardware/types" }
 sled-storage = { path = "sled-storage" }

clippy.toml

@@ -15,5 +15,5 @@ disallowed-methods = [
     # and can fail spuriously.
     # Instead, the "transaction_retry_wrapper" should be preferred, as it
     # automatically retries transactions experiencing contention.
-    { path = "async_bb8_diesel::AsyncConnection::transaction_async", reason = "Prefer to use transaction_retry_wrapper, if possible. Feel free to override this for tests and nested transactions." },
+    { path = "async_bb8_diesel::AsyncConnection::transaction_async", reason = "Prefer to use transaction_retry_wrapper, if possible. For tests and nested transactions, use transaction_non_retry_wrapper to at least get dtrace probes" },
 ]

dev-tools/ls-apis/README.adoc

@@ -104,6 +104,30 @@ You can generate a PNG image of the graph like this:
 $ dot -T png -o deployment-units.png deployment-units.dot
 ```
 
+=== Checking the upgrade DAG
+
+As of this writing:
+
+* All Dropshot/Progenitor APIs in the system are identified with this tool (as far as we know).
+* Every API is annotated with metadata in `api-manifest.toml`.
+* The API metadata specifies whether versioning for the API is managed on the server side exclusively or using client-side versioning as well.  We've made this choice for every existing API.
+* There are no cycles in the server-side-managed-API dependency graph.
+
+This tool verifies these properties.  If you add a new API or a new API dependency without adding valid metadata, or if that metadata breaks these constraints, you will have to fix this up before you can land the change to Omicron.
+
+You can verify the versioning metadata using:
+
+```
+$ cargo xtask ls-apis check
+```
+
+You might see any of the following errors:
+
+* `+missing field `versioned_how`+`: this probably means that you added an API to the metadata but neglected to specify the `versioned_how` field.  This must be either `client` or `server`.  In general, prefer `server`.  The tool should tell you if you try to use `server` but that can't work.  If in doubt, ask the update team.
+* `at least one API has unknown version strategy (see above)`: this probably means you added an API with `version_how = "unknown"`.  (The specific API(s) with this problem are listed immediately above this error.)  You need to instead decide if it should be client-side or server-side versioned.  If in doubt, ask the update team.
+* `+missing field `versioned_how_reason`+`: this probably means that you added an API with `versioned_how = "client"`, but did not add a `versioned_how_reason`.  This field is required.  It's a free-text field that explains why we couldn't use server-side versioning for this API.
+* `graph of server-managed components has a cycle (includes node: "omicron-nexus")`: this probably means that you added an API with `versioned_how = "server"`, but that created a circular dependency with other server-side-versioned components.  You'll need to break the cycle by changing one of these components (probably your new one) to be client-managed instead.
+* `API identified by client package "nexus-client" (Nexus Internal API) is the "client" in a "non-dag" dependency rule, but its "versioned_how" is not "client"` (the specific APIs may be different): this (unlikely) condition means just what it says: the API manifest file contains a dependency rule saying that some API is *not* part of the update DAG, but that API is not marked accordingly.  See the documentation below on filter rules.
 
 == Details