Skip to content

Conversation

nephomaniac
Copy link
Contributor

@nephomaniac nephomaniac commented Apr 2, 2025

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.


Example:

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
    bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(ocmConnection) 
    restcfg, err := bplogin.GetRestConfigWithConn(bpcfg, ocmConnection, clusterID)
    return  k8sclient.New(restcfg, options)
}


// Fake function to create ocm sdk connections using provided ocmConfig. 
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.  
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...} 

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both hive(s) and a target cluster(s) connections can only be used in prod. 
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...
 
func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string)  {
   doClusterSync(hiveClient, clusterID)
   checkStuff(clusterClient) 
}  

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
   // Requires cluster access...
   clusterResource := fetchClusterResourceThing(clusterClient)
   // Requires Hive access... 
   cloudAPI := getCloudAPIConnection(hiveClient, clusterID) 
   
   fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

@openshift-ci-robot
Copy link

openshift-ci-robot commented Apr 2, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • [ X] Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Apr 2, 2025
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 2, 2025
Copy link
Contributor

openshift-ci bot commented Apr 2, 2025

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci-robot
Copy link

openshift-ci-robot commented Apr 2, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • [ X] Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Apr 2, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

Copy link
Contributor

openshift-ci bot commented Apr 2, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: nephomaniac
Once this PR has been reviewed and has the lgtm label, please assign hectorakemp for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found 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

@nephomaniac
Copy link
Contributor Author

/test all

@codecov-commenter
Copy link

codecov-commenter commented Apr 2, 2025

Codecov Report

❌ Patch coverage is 28.07018% with 41 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.54%. Comparing base (1963392) to head (9391fee).

Files with missing lines Patch % Lines
cmd/ocm-backplane/login/login.go 25.00% 13 Missing and 2 partials ⚠️
pkg/cli/config/config.go 45.83% 12 Missing and 1 partial ⚠️
pkg/backplaneapi/clientUtils.go 0.00% 8 Missing ⚠️
pkg/ocm/ocm.go 0.00% 5 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #657      +/-   ##
==========================================
- Coverage   52.82%   52.54%   -0.29%     
==========================================
  Files          80       80              
  Lines        6065     6113      +48     
==========================================
+ Hits         3204     3212       +8     
- Misses       2434     2471      +37     
- Partials      427      430       +3     
Files with missing lines Coverage Δ
pkg/ocm/ocm.go 4.11% <0.00%> (-0.07%) ⬇️
pkg/backplaneapi/clientUtils.go 0.00% <0.00%> (ø)
pkg/cli/config/config.go 70.83% <45.83%> (-4.42%) ⬇️
cmd/ocm-backplane/login/login.go 66.25% <25.00%> (-2.06%) ⬇️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@nephomaniac
Copy link
Contributor Author

/test lint

@nephomaniac
Copy link
Contributor Author

/test all

@nephomaniac nephomaniac marked this pull request as ready for review May 5, 2025 23:43
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 5, 2025
@openshift-ci openshift-ci bot requested review from Dee-6777 and diakovnec May 5, 2025 23:43
@openshift-ci-robot
Copy link

openshift-ci-robot commented May 12, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented May 12, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented May 22, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

Copy link
Member

@typeid typeid left a comment

Choose a reason for hiding this comment

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

Not a detailed review and not a blocker for this PR:
given recent discussions, we really need a refactor the logic we share across tools out of /cmd/ into /pkg/ - and changes to these functions with care and knowledge around their consumers (CAD, osdctl).

@feichashao
Copy link
Contributor

Hi @nephomaniac , could you check the comments by @samanthajayasinghe when you have capacity? Thanks!

@samanthajayasinghe
Copy link
Contributor

Let's hold this PR for now

@samanthajayasinghe
Copy link
Contributor

/hold

@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 Aug 20, 2025
@nephomaniac
Copy link
Contributor Author

Hi @samanthajayasinghe sorry for the delay on this. I took some time to investigate a larger refactor, but not sure it's appropriate for this specific change/benefit. Please let me know if there's anything I can do to move this (or similar/smaller change forward). Thank you!

@samanthajayasinghe
Copy link
Contributor

FYI @nephomaniac , we recently merged the singleton OCM connection with a timeout. Does this resolve the original issue?
ocm connection PR: #785

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 1, 2025
@nephomaniac
Copy link
Contributor Author

FYI @nephomaniac , we recently merged the singleton OCM connection with a timeout. Does this resolve the original issue? ocm connection PR: #785

Hi @samanthajayasinghe thanks for the heads up. It's possible the PR: #785 can help a little, but at first glance I think it may also introduce new areas for OCM connection inconsistencies(?). (IMO) It would be ideal to separate the config/building-config functions from those that create connections with the config. Allowing the consumer to persist a desired OCM config throughout the life of a BP OcmInterface impl.

It appears that with PR: #785 an OCM connection's config can be inadvertently changed to a completely different connection context/env during the active/ongoing use of the OCM itfc impl (ie due to the timeouts, auto-recreation of the underlying connection)?
Allowing the consumer to persist OCM config, and be deliberate in when/how OCM config changes are applied to the underlying connections may be a nice complement to PR: #785?
Thanks!

@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 1, 2025
Copy link
Contributor

openshift-ci bot commented Oct 1, 2025

@nephomaniac: all tests passed!

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-sigs/prow repository. I understand the commands that are listed here.

@nephomaniac
Copy link
Contributor Author

/label tide/merge-method-squash

@openshift-ci openshift-ci bot added the tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. label Oct 1, 2025
@samanthajayasinghe
Copy link
Contributor

Thanks for the info, @nephomaniac. As I understand it, this PR fundamentally addresses switching the OCM environment since stage/int Hive clusters are on the production environment.
I'm not entirely clear about the root issue we're addressing here, but I agree that configuring the OCM token/file can be separate from the backplane configuration.
My understanding is that we may need a DDR to describe the issue and potential solution that satisfies both the managed OpenShift and FredRamp environments.
I'll seek other thoughts on how we can proceed with this PR further.
cc : @bmeng / @smarthall / @feichashao / @xiaoyu74

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 1, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.

Example:

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(prodOcmConn)
rstcfg, err := bplogin.GetRestConfigWithConn(bp, hiveOcmConn, clusterID)
return k8sclient.New(cfg, options)
}

// Fake function to create ocm sdk connections using provided ocmConfig.
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...}

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both and target cluster connections can only be used in prod.
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...

func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string) {
doClusterSync(hiveClient, clusterID)
checkStuff(clusterClient)
}

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
// Requires cluster access...
clusterResource := fetchClusterResourceThing(clusterClient)
// Requires Hive access...
cloudAPI := getCloudAPIConnection(hiveClient, clusterID)

fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@nephomaniac
Copy link
Contributor Author

nephomaniac commented Oct 1, 2025

Thanks. I've updated the PR description with an example. This PR allows consumers of backplane-cli to create backplane client connections with a provided ocm sdk connection, ...which allows the consumer to separate the ocm config building portions from backplane-cli.
The sudo example I provided above uses the new BP-cli wrapper functions like this...

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
    bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(ocmConnection) 
    restcfg, err := bplogin.GetRestConfigWithConn(bpcfg, ocmConnection, clusterID)
    return  k8sclient.New(restcfg, options)
}

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 1, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.

Example:

`//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(prodOcmConn)
rstcfg, err := bplogin.GetRestConfigWithConn(bp, hiveOcmConn, clusterID)
return k8sclient.New(cfg, options)
}

// Fake function to create ocm sdk connections using provided ocmConfig.
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...}

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both and target cluster connections can only be used in prod.
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...

func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string) {
doClusterSync(hiveClient, clusterID)
checkStuff(clusterClient)
}

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
// Requires cluster access...
clusterResource := fetchClusterResourceThing(clusterClient)
// Requires Hive access...
cloudAPI := getCloudAPIConnection(hiveClient, clusterID)

fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}
`

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 1, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.

Example:

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
   bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(prodOcmConn) 
   rstcfg, err := bplogin.GetRestConfigWithConn(bp, hiveOcmConn, clusterID)
   return  k8sclient.New(cfg, options)
}


// Fake function to create ocm sdk connections using provided ocmConfig. 
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.  
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...} 

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both and target cluster connections can only be used in prod. 
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...

func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string)  {
  doClusterSync(hiveClient, clusterID)
  checkStuff(clusterClient) 
}  

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
  // Requires cluster access...
  clusterResource := fetchClusterResourceThing(clusterClient)
  // Requires Hive access... 
  cloudAPI := getCloudAPIConnection(hiveClient, clusterID) 
  
  fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 1, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.

Example:

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
   bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(prodOcmConn) 
   rstcfg, err := bplogin.GetRestConfigWithConn(bp, hiveOcmConn, clusterID)
   return  k8sclient.New(cfg, options)
}


// Fake function to create ocm sdk connections using provided ocmConfig. 
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.  
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...} 

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both hive(s) and a target cluster(s) connections can only be used in prod. 
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...

func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string)  {
  doClusterSync(hiveClient, clusterID)
  checkStuff(clusterClient) 
}  

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
  // Requires cluster access...
  clusterResource := fetchClusterResourceThing(clusterClient)
  // Requires Hive access... 
  cloudAPI := getCloudAPIConnection(hiveClient, clusterID) 
  
  fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 1, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.

Example:

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
   bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(prodOcmConn) 
   restcfg, err := bplogin.GetRestConfigWithConn(bp, hiveOcmConn, clusterID)
   return  k8sclient.New(restcfg, options)
}


// Fake function to create ocm sdk connections using provided ocmConfig. 
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.  
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...} 

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both hive(s) and a target cluster(s) connections can only be used in prod. 
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...

func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string)  {
  doClusterSync(hiveClient, clusterID)
  checkStuff(clusterClient) 
}  

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
  // Requires cluster access...
  clusterResource := fetchClusterResourceThing(clusterClient)
  // Requires Hive access... 
  cloudAPI := getCloudAPIConnection(hiveClient, clusterID) 
  
  fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 1, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.

Example:

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
   bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(ocmConnection) 
   restcfg, err := bplogin.GetRestConfigWithConn(bpcfg, ocmConnection, clusterID)
   return  k8sclient.New(restcfg, options)
}


// Fake function to create ocm sdk connections using provided ocmConfig. 
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.  
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...} 

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both hive(s) and a target cluster(s) connections can only be used in prod. 
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...

func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string)  {
  doClusterSync(hiveClient, clusterID)
  checkStuff(clusterClient) 
}  

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
  // Requires cluster access...
  clusterResource := fetchClusterResourceThing(clusterClient)
  // Requires Hive access... 
  cloudAPI := getCloudAPIConnection(hiveClient, clusterID) 
  
  fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 2, 2025

@nephomaniac: This pull request references OSD-28241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

What type of PR is this?

  • Bug
  • Feature
  • Documentation
  • Test Coverage
  • Clean Up
  • Others

What this PR does / Why we need it?

This PR allows an OCM connection to be provided to the config building and login functions. ie adding new '*WithConn()' function variants allowing the caller to provide the OCM connection. This PR attempts to allow utils sharing backplane code to interact with clusters which reside in different OCM envs within the same executable. The most relevant use case is testing/developing within pre-production STAGE and INTEGRATION OCM envs, that are serviced by Hive clusters which exist in OCM Production environment(s)

  • Today as part of the client connection setup/code-path, it is not possible to create a clean separation of OCM config to be provided to multiple backplane connections within a single executable. It appears that through a chain of functions, the use of env vars prevents this from working as desired.

  • These changes also help avoid rebuilding/tearing down multiple OCM connections during the config + login phases.

  • This may make the build/login path more consistent with regard to the OCM attributes they use. Rebuilding/refetching OCM attributes may introduce (small) windows for race conditions.

This PR is an attempt at the least intrusive method of allowing a consumer to build and persist an OCM config/connection throughout the lifecycle of a BP-client connection.


Example:

//Example using new '*withConn' functions from this PR...
func CreateBPClient(ocmConnection *ocmsdk.Connection, clusterID string) (*k8sClient, error) {
   bpcfg, err := bpconfig.GetBackplaneConfigurationWithConn(ocmConnection) 
   restcfg, err := bplogin.GetRestConfigWithConn(bpcfg, ocmConnection, clusterID)
   return  k8sclient.New(restcfg, options)
}


// Fake function to create ocm sdk connections using provided ocmConfig. 
// The author can decide how the config is built, this PR allows this config to persist through the BP clients later.  
func RandomOCMSDKConnectionBuilder(*ocmConfig.Config) (*sdk.Connection, error) { ..some code...} 

// Create an OCM connection for each OCM environment...
prodOcmConn := RandomOCMSDKConnectionBuilder( prodOCMConfig)
stageOcmConn := RandomOCMSDKConnectionBuilder( stageOCMConfig)
intOcmConn := RandomOCMSDKConnectionBuilder( intOCMConfig)

// Create the needed Hive BP clients using prod...
hiveBPClientA := CreateBPClient(prodOcmConn, hiveClusterIdA)
hiveBPClientB := CreateBPClient(prodOcmConn, hiveClusterIdB)

// Create the target cluster BP clients using prod, stage, and int...
prodClusterBPClient := CreateBPClient(prodOcmConn, prodClusterIdB)
stagingClusterBPClient := CreateBPClient(stageOcmConn, stageClusterId)
intClusterBPClient := CreateBPClient(intOcmConn, intClusterId)

// Sample use cases with the artifacts created above...
// Today ALL osdctl utils that work with both hive(s) and a target cluster(s) connections can only be used in prod. 
// With this PR these utils no longer have to share the same production OCM environment.
// Some example/sudo use case we have today...

func doHiveClusterSyncAndCheckCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string)  {
  doClusterSync(hiveClient, clusterID)
  checkStuff(clusterClient) 
}  

func doFetchCloudStuffForCluster(hiveClient *k8sClient, clusterClient *k8sClient, clusterID string){
  // Requires cluster access...
  clusterResource := fetchClusterResourceThing(clusterClient)
  // Requires Hive access... 
  cloudAPI := getCloudAPIConnection(hiveClient, clusterID) 
  
  fetchCloudResourceBackingClusterResource(cloudAPI, clusterResource)
}

Which Jira/Github issue(s) does this PR fix?

Special notes for your reviewer

After initial draft review, additional unit tests should be added.

Unit Test Coverage

Waiting for initial draft review, before adding remaining unit tests.
I've manually tested this branch against OSDCTL using both legacy backplane functions, and new OCM sdk connection fed backplane functions. I've connected to clusters using each path, as well as mixing these within a single util. I've also tested basic ocm-backplane login cli connections in the terminal.

Guidelines

  • If it's a new sub-command or new function to an existing sub-command, please cover at least 50% of the code
  • If it's a bug fix for an existing sub-command, please cover 70% of the code

Test coverage checks

  • Added unit tests
  • Created jira card to add unit test
  • This PR may not need unit tests

Pre-checks (if applicable)

  • Ran unit tests locally
  • Validated the changes in a cluster
  • Included documentation changes with PR

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 openshift-eng/jira-lifecycle-plugin repository.

@xiaoyu74
Copy link
Contributor

xiaoyu74 commented Oct 2, 2025

My understanding is that we may need a DDR to describe the issue and potential solution that satisfies both the managed OpenShift and FredRamp environments.

IIUC, this PR just implemented to create 2 connections (prodConn and stageConn) mainly for osdctl that import bp-cli as a library (not for actual bp-cli end-users) to support multi-ocm-env in one call? Feeling no big arch change?

Also, FedRAMP env should be already isolated with different OCM URLs/infra, looks like this PR doesn't change FedRamp works but just non-gov multi-env testing, so, do we really think it's necessary to have a DDR?

btw, I may miss some context about #785, it should just reuse a single OCM connection and add auto-cleanup while this PR #657 implement to support multiple connection to different OCM env. So, the 2 PRs could be seen as complementary rather than conflicts? cc: @nephomaniac @samanthajayasinghe

@samanthajayasinghe
Copy link
Contributor

My understanding is that we may need a DDR to describe the issue and potential solution that satisfies both the managed OpenShift and FredRamp environments.

IIUC, this PR just implemented to create 2 connections (prodConn and stageConn) mainly for osdctl that import bp-cli as a library (not for actual bp-cli end-users) to support multi-ocm-env in one call? Feeling no big arch change?

Also, FedRAMP env should be already isolated with different OCM URLs/infra, looks like this PR doesn't change FedRamp works but just non-gov multi-env testing, so, do we really think it's necessary to have a DDR?

btw, I may miss some context about #785, it should just reuse a single OCM connection and add auto-cleanup while this PR #657 implement to support multiple connection to different OCM env. So, the 2 PRs could be seen as complementary rather than conflicts? cc: @nephomaniac @samanthajayasinghe

Thanks @xiaoyu74 and @nephomaniac for your thoughts and for updating the PR desc. If this PR is only for osdctl multi-ocm-env, then let's merge this PR.
I'll defer to you to merge the PR @xiaoyu74 / @bmeng

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants