Skip to content
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

chore: move model proxy to separate pkg #1521

Merged
merged 4 commits into from
Jan 15, 2025

Conversation

kian99
Copy link
Contributor

@kian99 kian99 commented Jan 14, 2025

Description

While working on intercepting SSH key methods in the model proxy and passing them to JIMM's business logic, I realised the model proxy should be in a different package. See the justification below.

The model proxy is currently housed within the rpc package. Originally I did this because the model proxy relied on the Juju RPC message definition declared in the rpc package. But this is likely not the right place for the model proxy as it has nothing to do with the dialer logic in the rpc package. Another supporting argument that the model proxy was in the wrong package is that the jimm package relies on the rpc package for dialing logic, but does not rely on the model proxy at all. And in fact, instead, the model proxy indirectly relies on the jimm package for business logic.

I also opted to move the streamproxy (used for proxying websocket connections that don't use Juju RPC like audit-logs) to its own package.

I've left some comments to explain the changes.

Partially fixes JUJU-7346

Engineering checklist

  • Documentation updated
  • Covered by unit tests
  • Covered by integration tests

@kian99 kian99 requested a review from a team as a code owner January 14, 2025 07:27
The model proxy is currently housed within the rpc package.
Originally I did this because the model proxy relied on the Juju RPC message definition declared in the rpc package.
But this  is likely not the right place for the model proxy as it has nothing to do with the dialer logic in the rpc package.
Another supporting argument that the model proxy was in the wrong package is that the jimm package relies on the rpc package for dialing logic, but does not rely on the model proxy at all.
And in fact, instead, the model proxy indirectly relies on the jimm package for business logic.
@kian99 kian99 force-pushed the intercept-ssh-commands-followup-1 branch from 1fd4cb0 to 6d1fe9c Compare January 14, 2025 07:40
@@ -46,3 +48,14 @@ func proxy(src base.Stream, dst base.Stream) error {
}
}
}

func unexpectedReadError(err error) bool {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The streamproxy was using this bit of logic also used by the rpcproxy. So I just copied it over for now since it's reasonably small.

Copy link
Contributor

Choose a reason for hiding this comment

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

i remember this logic to be the source of some flaky tests we had, we need to be careful copying this over. I would prefer to just create a rpcutils pkg instead

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I took some of the testing logic that was shared by the (now split) rpc, rpcproxy and streamproxy packages and brought them into a new package called rpctest to reduce duplication. Just some helper functions to start a test server with a method to start a websocket connection with the test server.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The tests in this file were mixed together with dialer tests and have been moved to rpcproxy_test.go since they are basic tests of the rpc proxy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The Juju message struct has been copied for use in this package. This format isn't expected to change until Juju's API rework so I don't expect this to be an issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These are the tests from client_test.go copied verbatim.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This file has only 1 (large) test. It tests that the login side of the rpc proxy works so I've just put it into a file that better reflects that.

@@ -203,16 +203,6 @@ func (c *Client) Call(ctx context.Context, facade string, version int, id, metho

select {
case <-ch:
permissionsRequired, err := checkPermissionsRequired(ctx, *respMsg)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The rpc package was using checkPermissionsRequired which now lives in rpcproxy.go. I've removed this as there is no need to check for the permissionsRequired error here.

Copy link
Contributor

@SimoneDutto SimoneDutto left a comment

Choose a reason for hiding this comment

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

lgtm, with a single comment

@@ -46,3 +48,14 @@ func proxy(src base.Stream, dst base.Stream) error {
}
}
}

func unexpectedReadError(err error) bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

i remember this logic to be the source of some flaky tests we had, we need to be careful copying this over. I would prefer to just create a rpcutils pkg instead

@kian99
Copy link
Contributor Author

kian99 commented Jan 15, 2025

i remember this logic to be the source of some flaky tests we had, we need to be careful copying this over. I would prefer to just create a rpcutils pkg instead

I'll hold off on an rpcutils pkg for now since I believe it would only contain that one function.

@kian99 kian99 merged commit 217bd0f into canonical:v3 Jan 15, 2025
4 checks passed
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