Skip to content

[external api] Set a default empty array for VpcFirewallRuleUpdate #8175

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

Merged
merged 1 commit into from
May 18, 2025

Conversation

karencfv
Copy link
Contributor

In our attempt to make the Go SDK generator less hacky oxidecomputer/oxide.go#283, we had the unexpected side effect of breaking our VpcFirewallRuleUpdateParams struct https://github.com/oxidecomputer/oxide.go/pull/283/files#diff-841a2b1b5f072b633551cac9c34c9732a722b415e297a1530b92d5988962062eR6810-R6811 due to Go's fun way of handling empty values. Using this API no longer allows us to delete the entirety of the firewall rules.

This commit sets an empty array as the default for rules following the pattern that other APIs use.
https://github.com/oxidecomputer/omicron/blob/main/nexus/types/src/external_api/params.rs#L1163-L1177

cc @sudomateo

@karencfv karencfv requested a review from david-crespo May 16, 2025 02:05
@karencfv karencfv changed the title [api] Set a default empty array for VpcFirewallRuleUpdate [external api] Set a default empty array for VpcFirewallRuleUpdate May 16, 2025
Copy link
Contributor

@sudomateo sudomateo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm cool with this change to be consistent with other APIs but I would have assumed even without this change setting rules to [] in the request body would have worked. Did the previous configuration enforce a non-empty array?

Oh, I think I see it now. The Go SDK has omitempty on the rules attribute so setting [] serializes to null. The rules attribute isn't nullable in omicron so the omitempty will remain in the Go SDK. Now sending null in the request body will allow omicron to default rules to []. Do I have that right?

@ahl ahl requested review from ahl and removed request for ahl May 16, 2025 13:48
@karencfv karencfv merged commit 62614ab into oxidecomputer:main May 18, 2025
17 checks passed
@karencfv karencfv deleted the fw-api-fix branch May 18, 2025 23:31
@david-crespo
Copy link
Contributor

Sorry, meant to comment on Friday. Does this make it so you can nuke all your rules by posting {} as the request body? That makes me slightly nervous as it’s a little surprising, though it will probably never happen. It feels like an API-side workaround for a client quirk, if I understand this omitempty correctly. There’s no way to make the SDK act normal, i.e., pass what you actually give it as the request body?

@sudomateo
Copy link
Contributor

sudomateo commented May 19, 2025

Sorry, meant to comment on Friday. Does this make it so you can nuke all your rules by posting {} as the request body? That makes me slightly nervous as it’s a little surprising, though it will probably never happen.

Correct. This is how the UI code also does it. If you delete the last firewall rule in the UI the request body that's sent is {"rules":[]} since there's no DELETE endpoint for firewall rules.

It feels like an API-side workaround for a client quirk, if I understand this omitempty correctly. There’s no way to make the SDK act normal, i.e., pass what you actually give it as the request body?

We could update the Go SDK to remove omitempty or change it to omitzero. That'll make the serialization like so.

rules: []string(nil)
no tag    -> {"rules":null}
omitempty -> {}
omitzero  -> {}

rules: []string{}
no tag    -> {"rules":[]}
omitempty -> {}
omitzero  -> {"rules":[]}

rules: []string{"foo"}
no tag    -> {"rules":["foo"]}
omitempty -> {"rules":["foo"]}
omitzero  -> {"rules":["foo"]}

@karencfv
Copy link
Contributor Author

UPDATE: Had a chat in the Product sync about this and we'll be continuing the conversation.

Just want to add a datapoint here. What we really need here is a DELETE endpoint. Right now I'm basically shoehorning the functionality into an endpoint that's just meant to update. If we want to protect users from accidentally deleting things and explicitly requiring rules for an update, a separate means to delete would be more correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants