oxidecomputer / oxidecomputer/omicron

blueprint-execution: Remove step that plumbs firewall rules

Open
#7,525 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

When this step was added to blueprint execution, it was required so sled-agent could get firewall rules for newly-deployed Nexus instances. Since then, the ServiceRulePropagator RPW has been added, which plumbs firewall rules periodically.

I think it would be fine to just delete the blueprint execution step entirely, but needs at least some basic testing to ensure that's right. The activation period for ServiceRulePropagator is currently pretty long (5 minutes), so there might be cases for:

  • shorten the ServiceRulePropagator period
  • have blueprint execution activate ServiceRulePropagator explicitly after deploying zones (I think this would be equivalent to the previous bullet? since we'd now be activating ServiceRulePropagator on the blueprint-execution period)
  • have blueprint execution activate ServiceRulePropagator explicitly after deploying zones if any new zones were added (I think this would require more information from sled-agent about what it did to handle a PUT /omicron-zones request)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the blueprint-execution step that plumbs firewall rules and reading the ServiceRulePropagator RPW behavior. Check how blueprint execution deploys zones and how sled-agent handles PUT /omicron-zones requests, then add basic tests that establish whether deleting the step preserves firewall-rule propagation and whether an explicit activation or period change is needed.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend, networking
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.