Conversation
|
Hi @FlorinPeter. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: FlorinPeter If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@FlorinPeter wouldn't the output generated by the installer be enough to then deploy the cluster on top of your infrastructure created with your self defined Terraform files? i'm trying to understand why the installer should extend its scope to allow custom terrafform files, what is the benefit ? is that going to be the case for majority of BYO users ? |
|
@DanyC97 from my point of view it is also a possibility to only consume the generated ignition files but the installer is currently not only generating the ignition files. |
|
close in favor of #1393 |
The motivation behind this PR is to be able to solve our security requirements by using our own Terraform files and plugins for the supported platforms.
The use of self defined Terraform files should always respecting the boundaries given by the installer.
If the byo is set via the install-config.yaml then the installer will not unpack the platform specific files and expects them in the specified installer directory.