Update OPTE

[plotnick]

Pull in OPTE version e6e197a08c086cfa4cdb2e58bf71c580f89229ac (which includes new default firewall actions and VNI filters),
update sled-agent for API changes, and remove default RDP firewall rule.

[plotnick]

This is my first OPTE update. I've tested this locally on Helios with a manual OPTE update, but how do we get the CI helios / deploy test passing? It's failing right now with BadApiVersion { user: 18, kernel: 15 } because the test isn't run with the new OPTE (the one this PR updates to); how do we update the test runner before merging this? Or do we override the test somehow?

[rzezeski]

The helios/deploy run relies on some custom built image. In the past we've asked @jclulow to update that for us.

[jclulow]

I would like to take this moment to request an enhancement to the OPTE packaging. Right now, we have this API version which seems to monotonically increase with incompatible changes, which is great. The package versioning scheme we have for the /driver/network/opte is currently based entirely on the commit number in the repository, so I believe the latest version is:

$ pkg list -g https://pkg.oxide.computer/helios-netdev opte
NAME (PUBLISHER)                                  VERSION                    IFO
driver/network/opte (helios-netdev)               0.1.138                    ---

Which comes from the head of master:

$ GIT_PAGER= git log -n 1
commit e6e197a08c086cfa4cdb2e58bf71c580f89229ac (HEAD -> master, origin/rpz-opte-294, origin/master, origin/HEAD)
Author: Ryan Zezeski <ryan@oxide.computer>
Date:   Fri Oct 28 14:29:14 2022 -0600

    xde does not update VPC mappings when a Port is deleted (#294)

$ git rev-list --count e6e197a08c086cfa4cdb2e58bf71c580f89229ac
138

It would, I think, be excellent if we could make the minor version (which is currently fixed to 1) represent this API version instead, so the latest version could instead be 0.18.138 (or, because it would require at least one commit to fix this, 0.18.139). Then it is much easier to talk about what version of the package you need: it would be 0.18.*.

Does that make sense?

[rzezeski]

@jclulow Yea that sounds like a fine idea. I'll go ahead and get a PR going for that in opte.

[rzezeski]

@jclulow made the version change in oxidecomputer/opte#296.

[jclulow]

@jclulow made the version change in oxidecomputer/opte#296.

Thank you, that's awesome! I have a new package now:

 $ pkgrepo list -s /ws/repo-netdev opte
PUBLISHER     NAME                                          O VERSION
helios-netdev driver/network/opte                             0.18.139:20221101T212758Z
helios-netdev driver/network/opte                             0.1.138:20221028T210406Z
helios-netdev driver/network/opte                             0.1.118:20220930T182311Z
helios-netdev driver/network/opte                             0.1.117:20220928T175045Z
helios-netdev driver/network/opte                             0.1.94:20220727T151742Z
helios-netdev driver/network/opte                             0.1.83:20220707T173450Z
helios-netdev driver/network/opte                             0.1.82:20220705T195845Z
helios-netdev driver/network/opte                             0.1.78:20220623T204810Z
helios-netdev driver/network/opte                             0.1.70:20220510T184450Z

I will endeavour to get the lab-netdev ramdisk updated.

[plotnick]

I will endeavour to get the lab-netdev ramdisk updated.

Howdy, @jclulow! This wasn't really blocking anything before (and I know you were slammed), but it seems like it's starting to do so. Could we possibly get that new ramdisk image?

[jclulow]

I will endeavour to get the lab-netdev ramdisk updated.

Howdy, @jclulow! This wasn't really blocking anything before (and I know you were slammed), but it seems like it's starting to do so. Could we possibly get that new ramdisk image?

Yes, I'm looking at the stuff Luqman added for generating the new images today! Sorry about the delay here.

[jclulow]

I have been able to build an image and get the target configured in buildomat, but regrettably it does not currently boot due to a regression introduced with oxidecomputer/stlouis#63. I'm putting this down for the weekend and I'll get another image built and report back on Monday after we've got that sorted out.

[rmustacc]

The additional details @jclulow asked for are in oxidecomputer/stlouis#272.

[luqmana]

@jclulow Looks like the fix for oxidecomputer/stlouis#272 has landed.

Were you going to keep the current lab-netdev image but just leave it as latest tag + additional versioned ones? (e.g. lab-netdev-18 which this PR would use)

EDIT: the versioned targets are setup now as lab-opte-0.x e.g. these changes require lab-opte-0.18

[luqmana]

Bumped the opte rev a bit forward to oxidecomputer/opte@f501445 (w/ corresponding lab-opte-0.19) to fix external connectivity regression due to the new fw defaults: incoming ARPs were getting dropped at the firewall layer before making it to the gateway layer that would do the proxy arp. This is still part of the external ip hack and can be removed soon (TM) but in the meantime don't want to break the existing flow.