-
Notifications
You must be signed in to change notification settings - Fork 79
[2/n] [reconfigurator] test that Reconfigurator updates are in server-side topological order #10099
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
5245858
a69d102
64f2717
36a7124
471b88c
9a65610
27599f8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -67,7 +67,7 @@ ignored_non_clients = [ | |
| # The host OS includes Sled Agent, Propolis, and all the components that get | ||
| # bundled into the switch zone. | ||
| [[deployment_units]] | ||
| label = "Host OS" | ||
| name = "Host OS" | ||
| packages = [ | ||
| "omicron-sled-agent", | ||
| "propolis-server", | ||
|
|
@@ -83,44 +83,49 @@ packages = [ | |
|
|
||
| # Installinator gets packaged into its own host OS image. | ||
| [[deployment_units]] | ||
| label = "Installinator" | ||
| name = "Installinator" | ||
| packages = [ "installinator" ] | ||
|
|
||
| # The rest of these get bundled by standard control plane zone images. | ||
|
|
||
| [[deployment_units]] | ||
| label = "Crucible" | ||
| name = "Crucible" | ||
| packages = [ "crucible-agent", "crucible-downstairs" ] | ||
|
|
||
| [[deployment_units]] | ||
| label = "Crucible Pantry" | ||
| name = "Crucible Pantry" | ||
| packages = [ "crucible-pantry" ] | ||
|
|
||
| [[deployment_units]] | ||
| label = "Cockroach" | ||
| name = "Cockroach" | ||
| packages = [ "omicron-cockroach-admin" ] | ||
|
|
||
| # These are really three distinct deployment units, but they behave the same for | ||
| # our purposes, and the tooling doesn't support multiple deployment units | ||
| # that each expose a particular service. | ||
| # This is really three distinct deployment units: | ||
| # | ||
| # * single-node ClickHouse | ||
| # * multi-node ClickHouse Server | ||
| # * multi-node ClickHouse Keeper | ||
| # | ||
| # but they behave the same for our purposes, and the tooling doesn't support | ||
| # multiple deployment units that each expose a particular service. | ||
| [[deployment_units]] | ||
| label = "Clickhouse (single-node) / Clickhouse Server (multi-node) / Clickhouse Keeper (multi-node)" | ||
| name = "ClickHouse" | ||
| packages = [ "omicron-clickhouse-admin" ] | ||
|
|
||
| [[deployment_units]] | ||
| label = "DNS Server" | ||
| name = "DNS Server" | ||
| packages = [ "dns-server" ] | ||
|
|
||
| [[deployment_units]] | ||
| label = "Nexus" | ||
| name = "Nexus" | ||
| packages = [ "omicron-nexus" ] | ||
|
|
||
| [[deployment_units]] | ||
| label = "NTP" | ||
| name = "NTP" | ||
| packages = [ "omicron-ntp-admin" ] | ||
|
|
||
| [[deployment_units]] | ||
| label = "Oximeter" | ||
| name = "Oximeter" | ||
| packages = [ "oximeter-collector" ] | ||
|
|
||
|
|
||
|
|
@@ -239,7 +244,11 @@ configuration and monitoring that requires the `cockroach` CLI. | |
| client_package_name = "ntp-admin-client" | ||
| label = "NTP Admin" | ||
| server_package_name = "ntp-admin-api" | ||
| versioned_how = "server" | ||
| versioned_how = "client" | ||
| versioned_how_reason = """ | ||
| Sled Agent (within the Host OS deployment unit) calls into NTP, and is updated \ | ||
| before NTP. This requires that the NTP Admin API be client-side versioned. | ||
| """ | ||
| notes = """ | ||
| This is the server running inside NTP zones that performs \ | ||
| monitoring on 'chrony'. | ||
|
|
@@ -475,9 +484,34 @@ instance. It's also used by `crutest` for testing. | |
| # edges should be in that graph. | ||
| # | ||
|
|
||
| # | ||
| # RSS-only dependencies. These are real dependencies that only exist during | ||
| # RSS, not during normal operation or upgrade. | ||
| # | ||
| # At RSS time, the system is known to be at a single, consistent version. | ||
| # | ||
| [[dependency_filter_rules]] | ||
| ancestor = "omicron-sled-agent" | ||
| client = "cockroach-admin-client" | ||
| evaluation = "rss-only" | ||
| note = """ | ||
| Sled Agent only uses the Cockroach Admin client during RSS, which we don't care | ||
| about for the purpose of upgrade. | ||
| """ | ||
|
|
||
| [[dependency_filter_rules]] | ||
| ancestor = "omicron-sled-agent" | ||
| client = "dns-service-client" | ||
| evaluation = "rss-only" | ||
| note = """ | ||
| Sled Agent only uses the DNS service client during RSS, which we don't care | ||
| about for the purpose of upgrade. | ||
| """ | ||
|
Comment on lines
+493
to
+509
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We also discussed putting RSS into its own package so that we could eliminate the risk that some other part of sled agent grows these dependencies. Do you have any idea how much work that is? Seems at least worth filing an issue.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I haven't looked too deeply into this. I'll file an issue. |
||
|
|
||
|
sunshowers marked this conversation as resolved.
|
||
| # | ||
| # Non-DAG dependencies. See above for details. | ||
| # | ||
|
|
||
| [[dependency_filter_rules]] | ||
| ancestor = "oximeter-producer" | ||
| client = "nexus-client" | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that:
The first one seems better for the reasons we've previously discussed not wanting to accumulate delta (it makes it harder for future people to see what their changes were) but I guess either is okay right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the latter, matching the other client-side API versions. I would really like to preserve the property that blessed versions are immutable if at all possible.
One possibility here for future work is introducing something like a minor version (1.1, 1.2, etc), where the minor versions are always wire compatible with the corresponding major version (1.0, etc). Then, we clients can be instructed to send 1.0 in their
api-versionheader rather than 1.1, etc. I haven't fully thought this through so it's possible there are issues with this approach.