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

CONSOLE-3171, CONSOLE-3329: Re-initialize graphql client on cluster change #12425

Closed
wants to merge 1 commit into from

Conversation

rawagner
Copy link
Contributor

No description provided.

@openshift-ci openshift-ci bot requested review from florkbr and kyoto January 10, 2023 21:45
@openshift-ci openshift-ci bot added component/backend Related to backend component/core Related to console core functionality component/shared Related to console-shared labels Jan 10, 2023
Comment on lines 123 to 125
startGQLClient();
dispatch(clearSSARFlags());
dispatch(detectFeatures());
Copy link
Contributor Author

@rawagner rawagner Jan 10, 2023

Choose a reason for hiding this comment

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

I think we should create a function which will do all the necessary dispatches as these 3 function calls are being repeated in couple more places.

Also I think we should re-run API discovery

Copy link
Member

Choose a reason for hiding this comment

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

Feel free to add the api discovery here. We only left it out because we knew it wouldn't work yet :)

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 will create a separate PR for that. There is some caching involved on frontend side so Im not sure that running just dispatch(startAPIDiscovery()) will be correct.

Comment on lines +356 to +365
handle(graphQLEndpoint, authHandlerWithUser(func(user *auth.User, w http.ResponseWriter, r *http.Request) {
cluster := serverutils.GetCluster(r)
k8sProxyConfig := s.getK8sProxyConfig(cluster)
k8sProxy := proxy.NewProxy(k8sProxyConfig)
k8sResolver := resolver.K8sResolver{K8sProxy: k8sProxy}
rootResolver := resolver.RootResolver{K8sResolver: &k8sResolver}
schema := graphql.MustParseSchema(string(graphQLSchema), &rootResolver, opts...)
handler := graphqlws.NewHandler()
handler.InitPayload = resolver.InitPayload
graphQLHandler := handler.NewHandlerFunc(schema, &relay.Handler{Schema: schema})
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@TheRealJon you already had the backend part implemented :)

Copy link
Member

Choose a reason for hiding this comment

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

I'm about to change this implementation a little, but it should be an easy adjustment. Instead of creating a new proxy instance on every request, we should create one on the first request, then reuse the same proxy instance on subsequent requests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that is happening already IIUC. The handle function is executed once, when graphl client tries to connect to graphql server - we create a proxy and graphql handler here. The rest of the communication is done via websocket and the graphql handler is always using the same proxy instance.
When the cluster is changed in the UI, the websocket is closed and new one is created, executing the handle function again (with new cluster as parameter)

Copy link
Member

Choose a reason for hiding this comment

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

Yes, but I think the number of proxy instances still scales up with the number of requests, which is probably not a scalable solution. With many users/sessions, proxy instances increase.

@rawagner rawagner changed the title CONSOLE-3171, CONSOLE-3329: Re-initialize graphql client on cluster change CONSOLE-3171: Re-initialize graphql client on cluster change Jan 10, 2023
@rawagner rawagner changed the title CONSOLE-3171: Re-initialize graphql client on cluster change CONSOLE-3171, CONSOLE-3329: Re-initialize graphql client on cluster change Jan 11, 2023
Copy link
Member

@TheRealJon TheRealJon left a comment

Choose a reason for hiding this comment

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

A couple of questions and nits, but this is awesome!

frontend/public/graphql/client.ts Outdated Show resolved Hide resolved
frontend/public/graphql/client.ts Outdated Show resolved Hide resolved
Comment on lines +356 to +365
handle(graphQLEndpoint, authHandlerWithUser(func(user *auth.User, w http.ResponseWriter, r *http.Request) {
cluster := serverutils.GetCluster(r)
k8sProxyConfig := s.getK8sProxyConfig(cluster)
k8sProxy := proxy.NewProxy(k8sProxyConfig)
k8sResolver := resolver.K8sResolver{K8sProxy: k8sProxy}
rootResolver := resolver.RootResolver{K8sResolver: &k8sResolver}
schema := graphql.MustParseSchema(string(graphQLSchema), &rootResolver, opts...)
handler := graphqlws.NewHandler()
handler.InitPayload = resolver.InitPayload
graphQLHandler := handler.NewHandlerFunc(schema, &relay.Handler{Schema: schema})
Copy link
Member

Choose a reason for hiding this comment

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

I'm about to change this implementation a little, but it should be an easy adjustment. Instead of creating a new proxy instance on every request, we should create one on the first request, then reuse the same proxy instance on subsequent requests.

Comment on lines 123 to 125
startGQLClient();
dispatch(clearSSARFlags());
dispatch(detectFeatures());
Copy link
Member

Choose a reason for hiding this comment

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

Feel free to add the api discovery here. We only left it out because we knew it wouldn't work yet :)

Copy link
Member

@jhadvig jhadvig left a comment

Choose a reason for hiding this comment

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

/lgtm

QE Approver:

/assign @yapei
Docs Approver:

/assign @opayne1
PX Approver:
/assign @RickJWagner

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 1, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 1, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jhadvig, rawagner

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 1, 2023
Copy link
Contributor

@opayne1 opayne1 left a comment

Choose a reason for hiding this comment

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

/label docs-approved

@openshift-ci openshift-ci bot added the docs-approved Signifies that Docs has signed off on this PR label Feb 1, 2023
@RickJWagner
Copy link

/label px-approved

@openshift-ci openshift-ci bot added the px-approved Signifies that Product Support has signed off on this PR label Feb 1, 2023
@jhadvig
Copy link
Member

jhadvig commented Feb 3, 2023

/test e2e-gcp-console

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 5, 2023
@yapei
Copy link
Contributor

yapei commented Feb 6, 2023

@rawagner Could you help rebase to master?

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Feb 6, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 6, 2023

New changes are detected. LGTM label has been removed.

@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 6, 2023
@yapei
Copy link
Contributor

yapei commented Feb 8, 2023

websocket connection to /api/graphql is re-established whenever we switch to managed cluster

wss://<console_route>/api/graphql?cluster=local-cluster
wss://<console_route>/api/graphql?cluster=usmng-176108

/label qe-approved

@openshift-ci openshift-ci bot added the qe-approved Signifies that QE has signed off on this PR label Feb 8, 2023
@jhadvig
Copy link
Member

jhadvig commented Feb 8, 2023

/test e2e-gcp-console

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 8, 2023

@rawagner: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-gcp-console 6916fae link true /test e2e-gcp-console

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Copy link
Member

@TheRealJon TheRealJon left a comment

Choose a reason for hiding this comment

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

During our testathon, these changes were deployed and a few regressions were noted that are related:

  • User settings fail to load when managed clusters are selected since the user UID changes. We are only fetching the user settings configmap from the hub cluster, and we use the user UID as part of the configmap name. We probably need to either track the hub cluster user UID separately to make sure we fetch the correct configmap, or update the user settings logic to fall back to local storage in a multicluster environment.
  • I experienced 401 responses from graphql when logged in as a user with cluster viewer permissions.
  • API discovery still needs to be addressed.

We can probably merge this and address the issues in a follow-on PR, but I just wanted to make sure we have these documented.

@jhadvig
Copy link
Member

jhadvig commented Feb 20, 2023

/hold
until we figure out what needs to be done with issues, mentioned in Jon's comment

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 20, 2023
@rawagner
Copy link
Contributor Author

Great findings, @TheRealJon
1 and 3 are pretty clear but Im not sure why 2 would occur. I dont know anything about cluster-viewer role.
Can we create sub-tasks for all of these and address them separately ?

@TheRealJon
Copy link
Member

Great findings, @TheRealJon 1 and 3 are pretty clear but Im not sure why 2 would occur. I dont know anything about cluster-viewer role. Can we create sub-tasks for all of these and address them separately ?

I'm hesitant to merge this without at least addressing 1 and 2 because those are pretty serious regressions. The API discovery issue might already have a bug in Jira and I'm fine tracking it separately since it's not introduced by these changes.

@TheRealJon
Copy link
Member

Multicluster feature has been deferred. Closing.

@TheRealJon TheRealJon closed this Mar 23, 2023
@TheRealJon
Copy link
Member

/jira refresh

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Mar 23, 2023
@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Mar 23, 2023

@TheRealJon: This pull request references CONSOLE-3329 which is a valid jira issue.

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@TheRealJon
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. component/backend Related to backend component/core Related to console core functionality component/shared Related to console-shared do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. docs-approved Signifies that Docs has signed off on this PR jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. multicluster px-approved Signifies that Product Support has signed off on this PR qe-approved Signifies that QE has signed off on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants