-
Notifications
You must be signed in to change notification settings - Fork 40
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
Track more kinds of datalinks on a sled #6208
Conversation
4c85d82
to
14bedbb
Compare
- Drop the old `physical_data_link:*` timeseries, in favor of an expanded `sled_data_link:*`. This includes the sled identifiers, and also the _kind_ of link, which incorporates physical, VNIC, and OPTE devices. Expunge the old timeseries. - Make the existing metrics manager into a small wrapper around a background task. Add message types for asking the task to start / stop tracking various things, for now just VNICs and OPTE ports. Physical links can also be tracked (but not untracked), which the sled agent does immediately after creating the task. - Add the metrics request queue to the instance manager, instance, and instance runner, and have the runner start / stop tracking the control VNIC and OPTE ports after booting the zone and before stopping it respectively. - Add the metrics request queue to the probe manager, and also start / stop tracking the links in the zones. - Add the metrics queue to the service manager. This one is more complicated, because this object has to exist before the `SledAgent` object itself, in order to start the switch zone. Instead, the manager is provided the queue when it's notified that the `SledAgent` exists, and at the same time tries to use the queue to notify the metrics task about the control VNIC that must have already been plumbed into the zone. The service manager also tracks / untracks the VNICs and OPTE ports for the _Omicron_ zones it starts, which is much simpler. - Add some helper methods into the `{Running,Installed}Zone}` types for listing the names of the control VNIC, bootstrap VNIC, and any OPTE port names. These are used to tell the metrics task what links to track. - Clean up a few straggling comments or references to the VNICs that were previously required between OPTE ports and the guest Viona driver. Those were removed in #5989.
14bedbb
to
26bc426
Compare
In addition to the units I added in the PR, I did a couple of quick tests installing the whole control plane on my dev machine. Here's what we see when starting everything up:
I also created and then started / stopped an instance a few times, and we can see the following:
That's the control VNIC and OPTE port for the guest being added / removed when the instance is started and stopped. |
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.
Still going through this @bnaecker, but adding the first runthrough.
- Hashmap over B-tree map - Return indicator of send failure, log failures to send at call site.
I'm going to merge with |
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.
physical_data_link:*
timeseries, in favor of an expandedsled_data_link:*
. This includes the sled identifiers, and also the kind of link, which incorporates physical, VNIC, and OPTE devices. Expunge the old timeseries.SledAgent
object itself, in order to start the switch zone. Instead, the manager is provided the queue when it's notified that theSledAgent
exists, and at the same time tries to use the queue to notify the metrics task about the control VNIC that must have already been plumbed into the zone. The service manager also tracks / untracks the VNICs and OPTE ports for the Omicron zones it starts, which is much simpler.{Running,Installed}Zone}
types for listing the names of the control VNIC, bootstrap VNIC, and any OPTE port names. These are used to tell the metrics task what links to track.