-
Epic
-
Resolution: Done
-
Normal
-
openshift-4.13
-
None
-
Add the ability to place pre-created (BYON) resources in a resource group separate from cluster resources
-
BU Product Work
-
False
-
None
-
False
-
Not Selected
-
Done
-
OCPSTRAT-381 - Follow-up features for IBM Cloud
-
Impediment
-
OCPSTRAT-381Follow-up features for IBM Cloud
-
0% To Do, 0% In Progress, 100% Done
Epic Goal
With this BYON support:
- shared resources (VPC, subnets) can be placed in the resource group specified by the `networkResourceGroupName` install config parameter.
- installer provisioned cluster resources will be placed in the resource group specified by the `resourceGroupName` install config parameter.
- `networkResourceGroupName` is a required parameter for the BYON scenario
- `resourceGroupName` is an optional parameter
Why is this important?
- This will allow customers (using IBM Cloud VPC BYON support) to organize pre-created / shared resources (VPC, subnets) in a resource group separate from installer provisioned cluster resources.
Scenarios
`networkResourceGroupName` NOT specified ==> non-BYON install scenario
- if `resourceGroupName` is specified, then ALL installer provisioned resources (VPC, subnets, cluster) will be placed in specified resource group (resource group must exist)
- if `resourceGroupName` is NOT specified, then ALL installer provisioned resources (VPC, subnets, cluster) will be placed in a resource group created during the install process
`networkResourceGroupName` specified ==> BYON install scenario (required for BYON scenario)
- `networkResourceGroupName` must contain pre-created/shared resources (VPC, subnets)
- if `resourceGroupName` is specified, then all installer provisioned cluster resources will be placed in specified resource group (resource group must exist)
- if `resourceGroupName` is NOT specified, then all installer provisioned cluster resources will be placed in a resource group created during the install process
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- ...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions::
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>
- links to
- mentioned on
(1 mentioned on)
1.
|
Docs Tracker | Closed | Mike Pytlak (Inactive) | ||
2.
|
PX Tracker | Closed | Unassigned | ||
3.
|
QE Tracker | Closed | Unassigned | ||
4.
|
TE Tracker | Closed | Unassigned |